August 2026 - Wine-Bugs - list.winehq.org

[Bug 26110] New: ole32/marshal test shows several valgrind warnings
by wine-bugs＠winehq.org Aug. 28, 2026

Aug. 28, 2026

http://bugs.winehq.org/show_bug.cgi?id=26110 Summary: ole32/marshal test shows several valgrind warnings Product: Wine Version: 1.3.13 Platform: x86 OS/Version: Linux Status: NEW Keywords: download, source, testcase Severity: normal Priority: P2 Component: ole32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: austinenglish(a)gmail.com Created an attachment (id=33290) --> (http://bugs.winehq.org/attachment.cgi?id=33290) valgrind log Syscall param write(buf) points to uninitialised byte(s) at ??? (in /lib/libpthread-2.11.2.so) by WriteFile (file.c:547) by rpcrt4_conn_np_write (rpc_transport.c:441) by rpcrt4_conn_write (rpc_binding.h:183) by RPCRT4_SendWithAuth (rpc_message.c:849) by RPCRT4_Send (rpc_message.c:1245) by process_request_packet (rpc_server.c:463) by RPCRT4_process_packet (rpc_server.c:518) by RPCRT4_worker_thread (rpc_server.c:540) by worker_thread_proc (threadpool.c:114) by ??? (signal_i386.c:2473) by call_thread_entry_point (signal_i386.c:2499) by start_thread (thread.c:404) by start_thread (in /lib/libpthread-2.11.2.so) by clone (in /lib/libc-2.11.2.so) Address 0x7f030894 is 44 bytes inside a block of size 92 alloc'd at notify_alloc (heap.c:254) by RtlAllocateHeap (heap.c:1701) by RPCRT4_SendWithAuth (rpc_message.c:808) by RPCRT4_Send (rpc_message.c:1245) by process_request_packet (rpc_server.c:463) by RPCRT4_process_packet (rpc_server.c:518) by RPCRT4_worker_thread (rpc_server.c:540) by worker_thread_proc (threadpool.c:114) by ??? (signal_i386.c:2473) by call_thread_entry_point (signal_i386.c:2499) by start_thread (thread.c:404) by start_thread (in /lib/libpthread-2.11.2.so) by clone (in /lib/libc-2.11.2.so) Uninitialised value was created by a client request at mark_block_uninitialized (heap.c:208) by initialize_block (heap.c:239) by RtlAllocateHeap (heap.c:1702) by IMalloc_fnAlloc (ifs.c:186) by CoTaskMemAlloc (ifs.c:395) by RemUnknown_RemQueryInterface (stubmanager.c:664) by IRemUnknown_RemQueryInterface_Stub (dcom_p.c:370) by CStdStubBuffer_Invoke (cstub.c:477) by RPC_ExecuteCall (rpc.c:1414) by apartment_wndproc (compobj.c:897) by ??? (winproc.c:172) by call_window_proc (winproc.c:242) by WINPROC_CallProcAtoW (winproc.c:601) by WINPROC_call_window (winproc.c:910) by DispatchMessageA (message.c:3639) by test_register_local_server (marshal.c:2625) by func_marshal (marshal.c:3067) by run_test (test.h:556) by main (test.h:624) ... 24 bytes in 1 blocks are definitely lost at notify_alloc (heap.c:254) by RtlAllocateHeap (heap.c:1701) by IDefClF_fnConstructor (shellole.c:386) by DllGetClassObject (shellole.c:219) by apartment_getclassobject (compobj.c:806) by apartment_hostobject (compobj.c:879) by apartment_wndproc (compobj.c:900) by ??? (winproc.c:172) by call_window_proc (winproc.c:242) by WINPROC_call_window (winproc.c:899) by call_window_proc (message.c:2201) by peek_message (message.c:2775) by GetMessageW (message.c:3511) by apartment_hostobject_thread (compobj.c:942) by ??? (signal_i386.c:2473) by call_thread_entry_point (signal_i386.c:2499) by start_thread (thread.c:404) by start_thread (in /lib/libpthread-2.11.2.so) by clone (in /lib/libc-2.11.2.so) ... 68 bytes in 1 blocks are definitely lost at notify_alloc (heap.c:254) by RtlAllocateHeap (heap.c:1701) by ClientRpcChannelBuffer_GetBuffer (rpc.c:634) by NdrProxyGetBuffer (cproxy.c:395) by IRemUnknown_RemRelease_Proxy (dcom_p.c:631) by ifproxy_release_public_refs (marshal.c:673) by ifproxy_destroy (marshal.c:708) by proxy_manager_destroy (marshal.c:1109) by ClientIdentity_Release (marshal.c:268) by IUnknown_Release_Proxy (cproxy.c:361) by test_no_couninitialize_server (marshal.c:894) by func_marshal (marshal.c:3095) by run_test (test.h:556) by main (test.h:624) ... 72 bytes in 1 blocks are definitely lost at notify_alloc (heap.c:254) by RtlAllocateHeap (heap.c:1701) by I_RpcAllocate (rpcrt4_main.c:705) by I_RpcGetBuffer (rpc_message.c:1647) by ClientRpcChannelBuffer_GetBuffer (rpc.c:721) by NdrProxyGetBuffer (cproxy.c:395) by IRemUnknown_RemRelease_Proxy (dcom_p.c:631) by ifproxy_release_public_refs (marshal.c:673) by ifproxy_destroy (marshal.c:708) by proxy_manager_destroy (marshal.c:1109) by ClientIdentity_Release (marshal.c:268) by IUnknown_Release_Proxy (cproxy.c:361) by test_marshal_stub_apartment_shutdown (marshal.c:744) by func_marshal (marshal.c:3092) by run_test (test.h:556) by main (test.h:624) ... 116 bytes in 1 blocks are definitely lost at notify_alloc (heap.c:254) by RtlAllocateHeap (heap.c:1701) by ClientRpcChannelBuffer_GetBuffer (rpc.c:638) by NdrProxyGetBuffer (cproxy.c:395) by IRemUnknown_RemRelease_Proxy (dcom_p.c:631) by ifproxy_release_public_refs (marshal.c:673) by ifproxy_destroy (marshal.c:708) by proxy_manager_destroy (marshal.c:1109) by ClientIdentity_Release (marshal.c:268) by IUnknown_Release_Proxy (cproxy.c:361) by test_no_couninitialize_server (marshal.c:894) by func_marshal (marshal.c:3095) by run_test (test.h:556) by main (test.h:624) and several possibly losts as well. Full log attached. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

2 5

[Bug 59530] New: wine-mono ignores color setting from theme / registry
by WineHQ Bugzilla Aug. 28, 2026

Aug. 28, 2026

http://bugs.winehq.org/show_bug.cgi?id=59530 Bug ID: 59530 Summary: wine-mono ignores color setting from theme / registry Product: Framework Mono Version: main Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mono Assignee: wine-bugs(a)list.winehq.org Reporter: andreas.franz(a)arcor.de CC: madewokherd(a)gmail.com Distribution: --- I'm using WineHQ 11.4 on Linux Mint (cinnamon desktop) with an .NET-application called MailStore Client. Background-Color ("control"-color) seems to be taken from (ugly) classic theme - WineHQ is set to Aero, though. With installed MS .NET 4.8, it looks like on real Windows-machines. So, I assume, colors are hardcoded at wine-mono? Is there any ENV to change this behaviour? I found "FEATURE_WINDOWS_SYSTEM_COLORS" on source-code, which decides if wine-mono reads colors from windows-system. But it seems to be a compiler-flag? Any ideas? regards, Andy -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 36675] New: urlmon/tests/protocol.c fail under valgrind
by wine-bugs＠winehq.org Aug. 28, 2026

Aug. 28, 2026

https://bugs.winehq.org/show_bug.cgi?id=36675 Bug ID: 36675 Summary: urlmon/tests/protocol.c fail under valgrind Product: Wine Version: 1.7.19 Hardware: x86 OS: Linux Status: NEW Keywords: download, source, testcase, valgrind Severity: normal Priority: P2 Component: urlmon Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com Created attachment 48717 --> https://bugs.winehq.org/attachment.cgi?id=48717 bt all ../../../tools/runtest -q -P wine -T ../../.. -M urlmon.dll -p urlmon_test.exe.so protocol && touch protocol.ok preloader: Warning: failed to reserve range 00110000-68000000 preloader: Warning: failed to reserve range 7f000000-82000000 fixme:wininet:create_cache_entry INTERNET_FLAG_NEED_FILE is not supported correctly err:ntdll:RtlpWaitForCriticalSection section 0x7bcd9ec4 "loader.c: loader_section" wait timed out in thread 007d, blocked by 0026, retrying (60 sec) protocol.c:329: Test failed: dwResponseCode=0, expected 200 protocol.c:1004: Test failed: ulProgress == 0 protocol.c:1012: Test failed: grcfBSCF = 00000005 protocol.c:628: Test failed: expected ReportData protocol.c:643: Test failed: expected ReportProgress_ACCEPTRANGES fixme:wininet:FtpGetFileSize (0x3, 0xb13d128) fixme:wininet:FTPFILE_LockRequestFile 0x480c198 make: *** [protocol.ok] Error 5 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 2

[Bug 36672] New: kernel32/tests/debugger.c fails under valgrind
by wine-bugs＠winehq.org Aug. 28, 2026

Aug. 28, 2026

https://bugs.winehq.org/show_bug.cgi?id=36672 Bug ID: 36672 Summary: kernel32/tests/debugger.c fails under valgrind Product: Wine Version: 1.7.19 Hardware: x86 OS: Linux Status: NEW Keywords: download, source, testcase, valgrind Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com wine: Unhandled page fault on write access to 0x00000000 at address 0x4c587ed (thread 0058), starting debugger... debugger.c:337: Test failed: Timed out waiting for the child to crash debugger.c:351: Test failed: wrong exit code : 00000103 wine: Unhandled page fault on write access to 0x00000000 at address 0x4c587ed (thread 003c), starting debugger... debugger.c:337: Test failed: Timed out waiting for the child to crash debugger.c:345: Test failed: wrong exit code : 00000103 wine: Unhandled page fault on write access to 0x00000000 at address 0x4c587ed (thread 0063), starting debugger... debugger.c:337: Test failed: Timed out waiting for the child to crash debugger.c:351: Test failed: wrong exit code : 00000103 wine: Unhandled page fault on write access to 0x00000000 at address 0x4c587ed (thread 0026), starting debugger... debugger.c:337: Test failed: Timed out waiting for the child to crash debugger.c:351: Test failed: wrong exit code : 00000103 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 3

[Bug 36614] New: valgrind shows a definite leak in rpcrt4/rpc_server.c process_request_packet()
by wine-bugs＠winehq.org Aug. 28, 2026

Aug. 28, 2026

https://bugs.winehq.org/show_bug.cgi?id=36614 Bug ID: 36614 Summary: valgrind shows a definite leak in rpcrt4/rpc_server.c process_request_packet() Product: Wine Version: 1.7.19 Hardware: x86 OS: Linux Status: NEW Keywords: download, source, testcase Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com ==15328== 81 bytes in 10 blocks are definitely lost in loss record 71 of 107 ==15328== at 0x7BC4C6DF: notify_alloc (heap.c:255) ==15328== by 0x7BC50F23: RtlAllocateHeap (heap.c:1716) ==15328== by 0x4EA25D5: I_RpcAllocate (rpcrt4_main.c:710) ==15328== by 0x4EA0134: RpcTransport_ParseTopOfTower (rpc_transport.c:3604) ==15328== by 0x4E8C6D7: TowerExplode (rpc_epmap.c:559) ==15328== by 0x495DA33: ept_map (epmp.c:219) ==15328== by 0x4960825: epm_ept_map (epm_s.c:744) ==15328== by 0x4E92AB2: process_request_packet (rpc_server.c:441) ==15328== by 0x4E92F06: RPCRT4_process_packet (rpc_server.c:519) ==15328== by 0x4E93099: RPCRT4_worker_thread (rpc_server.c:541) ==15328== by 0x7BC90A24: worker_thread_proc (threadpool.c:110) ==15328== by 0x7BC870C7: ??? (signal_i386.c:2571) ==15328== by 0x7BC87110: call_thread_func (signal_i386.c:2630) ==15328== by 0x7BC870A5: ??? (signal_i386.c:2571) ==15328== by 0x7BC8E4EC: start_thread (thread.c:428) ==15328== by 0x421FF92: start_thread (pthread_create.c:309) ==15328== by 0x43247ED: clone (clone.S:129) ==15328== This shows up at the end of make -k test, but I'm not sure which test causes it. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 4

[Bug 36586] New: valgrind shows uninitialized memory use in user32/tests/msg.c
by wine-bugs＠winehq.org Aug. 28, 2026

Aug. 28, 2026

https://bugs.winehq.org/show_bug.cgi?id=36586 Bug ID: 36586 Summary: valgrind shows uninitialized memory use in user32/tests/msg.c Product: Wine Version: 1.7.19 Hardware: x86 OS: Linux Status: NEW Keywords: download, source, testcase Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com ==27824== Conditional jump or move depends on uninitialised value(s) ==27824== at 0x427931D: vfprintf (vfprintf.c:1634) ==27824== by 0x429C4E1: vsprintf (iovsprintf.c:42) ==27824== by 0x428229E: sprintf (sprintf.c:32) ==27824== by 0x4D13DF4: add_message_ (msg.c:1994) ==27824== by 0x4D4338F: test_hotkey (msg.c:13929) ==27824== by 0x4D47490: func_msg (msg.c:14598) ==27824== by 0x4DA6978: run_test (test.h:584) ==27824== by 0x4DA6D67: main (test.h:654) ==27824== Uninitialised value was created by a stack allocation ==27824== at 0x4D41D56: test_hotkey (msg.c:13707) ==27824== Use of uninitialised value of size 4 ==27824== at 0x42780CD: _itoa_word (_itoa.c:180) ==27824== by 0x427B856: vfprintf (vfprintf.c:1634) ==27824== by 0x429C4E1: vsprintf (iovsprintf.c:42) ==27824== by 0x428229E: sprintf (sprintf.c:32) ==27824== by 0x4D13DF4: add_message_ (msg.c:1994) ==27824== by 0x4D4338F: test_hotkey (msg.c:13929) ==27824== by 0x4D47490: func_msg (msg.c:14598) ==27824== by 0x4DA6978: run_test (test.h:584) ==27824== by 0x4DA6D67: main (test.h:654) ==27824== Uninitialised value was created by a stack allocation ==27824== at 0x4D41D56: test_hotkey (msg.c:13707) ==27824== -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 3

[Bug 60215] New: esync: eventfd() exhaustion (EMFILE) on sync object creation not handled gracefully, propagates as guest null-pointer crash
by WineHQ Bugzilla Aug. 28, 2026

Aug. 28, 2026

http://bugs.winehq.org/show_bug.cgi?id=60215 Bug ID: 60215 Summary: esync: eventfd() exhaustion (EMFILE) on sync object creation not handled gracefully, propagates as guest null-pointer crash Product: Wine Version: unspecified Hardware: arm OS: Android Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: aydar.kamaltdinov(a)gmail.com Target Milestone: --- Note: this report was drafted/formatted with AI assistance (for structuring the technical writeup), but all testing, reproduction, log capture, and root-causing (attaching to the process's stderr, extracting the fault address/backtrace, confirming the WINEESYNC=0 workaround across multiple real runs) was done by me personally on physical hardware. Happy to answer follow-up questions or provide additional logs/raw captures directly. Possibly the same root cause as bug 58059 (eventfd leak in wineserver on thread create/destroy with WINEESYNC=1, UNCONFIRMED since 2025-04-04) — filing separately since I have a different real-world reproduction with more diagnostic detail (exact crash address + confirmed workaround), in case it helps unstick triage either way. Feel free to merge/dup if appropriate. ## Summary When WINEESYNC=1 is active and a running application leaks Windows synchronization objects (Events/Semaphores/etc.) faster than it releases them, esync's eventfd()-per-object model eventually exhausts the process's RLIMIT_NOFILE. At that point eventfd() creation fails with EMFILE, but the failure does not appear to be surfaced/handled in a way that prevents the guest application from later dereferencing an invalid/null handle — resulting in a hard crash (EXCEPTION_ACCESS_VIOLATION) instead of a recoverable API-level failure. This is architecture-independent in principle, but is far easier to trigger on platforms with a low default RLIMIT_NOFILE (e.g. Android, ~32768 in my case) than on typical desktop Linux, where the same underlying handle leak in the application would likely go unnoticed for a very long time (or indefinitely, given Windows' much larger practical handle-table ceiling). ## Observed on - A wine-staging-derived ARM64EC/WOW64 fork (used by several Android "run Windows games" projects — built from a "wine-proton-ec" tree, Proton 10.0 base), running on ARM64 Android via FEX-Emu as the WOW64 CPU backend. - I was not able to test on a vanilla x86-64 desktop Wine+wine-staging build to confirm the exact same code path applies verbatim, but the esync eventfd-creation code itself (dlls/ntdll/esync.c) appears architecture-independent, so I believe this is worth tracking upstream regardless of the specific fork. ## Reproduction case Game: Thief (2014), Steam AppID 239160, `Shipping-ThiefGame.exe`. Crashes deterministically (100% reproducible, identical fault address and full backtrace across repeated runs) during active gameplay with `WINEESYNC=1`. Captured via `WINEDEBUG=+seh,+exception`: code=c0000005 (EXCEPTION_ACCESS_VIOLATION) addr=000000014011F9D9 rip=000000014011f9d9 rcx=0000000000000000 ... Shipping-ThiefGame.exe+0x11F9D6: movq (%rbx), %rcx ; load object pointer Shipping-ThiefGame.exe+0x11F9D9: movq (%rcx), %rax <-- FAULT: rcx == 0 Shipping-ThiefGame.exe+0x11F9DC: callq *0x18(%rax) ; virtual call through vtable One capture shows this immediately preceding the crash: eventfd: Too many open files Setting `WINEESYNC=0` for this title eliminates the crash entirely (23+ minutes of gameplay with no crash, vs. a deterministic crash within minutes with esync on). ## Ask Is there existing handling in esync's object-creation path (CreateEvent/CreateSemaphore/etc. server calls) for eventfd() returning EMFILE? If not, would a graceful fallback (e.g. falling back to the non-esync/server-based wait object implementation for that single object, or returning a proper NT status the app is expected to check) be feasible, rather than leaving a handle in a state that leads to guest-side null dereferences? Happy to provide the full captured trace/disassembly if useful. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 36907] New: valgrind shows an unitialized variable in dlls/ieframe/tests/ie.c (nsEventStateManager::Release)
by wine-bugs＠winehq.org Aug. 28, 2026

Aug. 28, 2026

https://bugs.winehq.org/show_bug.cgi?id=36907 Bug ID: 36907 Summary: valgrind shows an unitialized variable in dlls/ieframe/tests/ie.c (nsEventStateManager::Release) Product: Wine Version: 1.7.22 Hardware: x86 OS: Linux Status: NEW Keywords: download, source, testcase, valgrind Severity: normal Priority: P2 Component: ieframe Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com ==24012== Conditional jump or move depends on uninitialised value(s) ==24012== at 0x103064CA: nsEventStateManager::Release (in /home/austin/.wine/drive_c/windows/system32/gecko/2.24/wine_gecko/xul.dll) ==24012== Uninitialised value was created by a client request ==24012== at 0x7BC4C4D6: mark_block_uninitialized (heap.c:209) ==24012== by 0x7BC4C641: initialize_block (heap.c:240) ==24012== by 0x7BC50F4D: RtlAllocateHeap (heap.c:1717) ==24012== by 0x6FA276B: msvcrt_heap_alloc (heap.c:70) ==24012== by 0x6FA3330: MSVCRT_malloc (heap.c:408) ==24012== by 0x80D71095: moz_xmalloc (mozalloc.cpp:54) ==24012== by 0x109B96F7: NS_InitXPCOM2 (nsxpcominit.cpp:464) ==24012== by 0x6D601B3: init_xpcom (nsembed.c:698) ==24012== by 0x6D60626: load_gecko (nsembed.c:774) ==24012== by 0x6D65013: create_nscontainer (nsembed.c:2042) ==24012== by 0x6CE5477: HTMLDocument_Create (htmldoc.c:4756) ==24012== by 0x6D4F178: ClassFactory_CreateInstance (main.c:238) ==24012== by 0x4EF20A2: CoCreateInstance (unknwn.h:226) ==24012== by 0x4E192B2: create_mime_object (binding.c:258) ==24012== by 0x4E19652: create_object (binding.c:308) ==24012== by 0x4E1C1E8: report_data (binding.c:1077) ==24012== by 0x4E1C531: InternetProtocolSink_ReportData (binding.c:1126) ==24012== by 0x4E218F0: ProtocolSinkHandler_ReportData (urlmon.h:3113) ==24012== by 0x4E22441: report_data_proc (urlmon.h:3113) ==24012== by 0x4E1E10E: process_tasks (bindprot.c:57) ==24012== -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 3

[Bug 36420] New: valgrind shows a possible leak in oledb32/tests/convert.c
by wine-bugs＠winehq.org Aug. 28, 2026

Aug. 28, 2026

https://bugs.winehq.org/show_bug.cgi?id=36420 Bug ID: 36420 Summary: valgrind shows a possible leak in oledb32/tests/convert.c Product: Wine Version: 1.7.18 Hardware: x86 OS: Linux Status: NEW Keywords: download, source, testcase Severity: normal Priority: P2 Component: oledb32 Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com ==4543== 28 bytes in 1 blocks are possibly lost in loss record 173 of 580 ==4543== at 0x7BC50A9B: RtlAllocateHeap (heap.c:255) ==4543== by 0x512CBB8: apartment_getclassobject (compobj.c:526) ==4543== by 0x512FFC6: get_inproc_class_object (compobj.c:2894) ==4543== by 0x5132D2F: CoGetClassObject (compobj.c:3032) ==4543== by 0x51334B7: CoCreateInstance (compobj.c:3197) ==4543== by 0x4B75932: test_dcinfo (convert.c:47) ==4543== by 0x4B84AFA: func_convert (convert.c:2908) ==4543== by 0x4B90E18: run_test (test.h:584) ==4543== by 0x4B91207: main (test.h:654) ==4543== -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 4

[Bug 36169] New: valgrind shows a possible leak in programs/services/tests/services.c
by wine-bugs＠winehq.org Aug. 28, 2026

Aug. 28, 2026

https://bugs.winehq.org/show_bug.cgi?id=36169 Bug ID: 36169 Summary: valgrind shows a possible leak in programs/services/tests/services.c Product: Wine Version: 1.7.17 Hardware: x86 OS: Linux Status: NEW Keywords: download, source, testcase Severity: normal Priority: P2 Component: programs Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com ==3856== 32 bytes in 1 blocks are possibly lost in loss record 32 of 104 ==3856== at 0x7BC4C6B7: notify_alloc (heap.c:255) ==3856== by 0x7BC50EFB: RtlAllocateHeap (heap.c:1716) ==3856== by 0x7BC39A6B: RtlInitializeCriticalSectionEx (critsection.c:326) ==3856== by 0x7B876AE5: InitializeCriticalSectionEx (sync.c:356) ==3856== by 0x7B876A64: InitializeCriticalSection (sync.c:313) ==3856== by 0x4A34B0E: test_runner (service.c:445) ==3856== by 0x4A34DAD: func_service (service.c:484) ==3856== by 0x4A35C5D: run_test (test.h:584) ==3856== by 0x4A3604B: main (test.h:654) ==3856== -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

3 4