February 2011 - Wine-bugs - list.winehq.org

[Bug 20919] New: Six tests usually or always hang in valgrind
by wine-bugs＠winehq.org 28 Sep '12

28 Sep '12

http://bugs.winehq.org/show_bug.cgi?id=20919 Summary: Six tests usually or always hang in valgrind Product: Wine Version: 1.1.33 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com The following six tests usually or always hang in Valgrind: kernel32 process.c ole32 marshal.c shdocvw webbrowser.c urlmon url.c winmm mci.c winmm wave.c I'll probably disable them in the test script to save the hour otherwise spent waiting for them to time out. -- 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.

1 13

[Bug 26106] New: ole32/ole2 tests show several valgrind warnings
by wine-bugs＠winehq.org 28 Sep '12

28 Sep '12

http://bugs.winehq.org/show_bug.cgi?id=26106 Summary: ole32/ole2 tests show several valgrind warnings Product: Wine Version: 1.3.13 Platform: x86 OS/Version: Linux Status: NEW Keywords: download, source, testcase Severity: minor Priority: P2 Component: ole32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: austinenglish(a)gmail.com Syscall param write(buf) points to uninitialised byte(s) at __write_nocancel (in /lib/libpthread-2.11.2.so) by WriteFile (file.c:547) by FileLockBytesImpl_WriteAt (filelockbytes.c:286) by StorageImpl_WriteAt (storage32.c:344) by StorageImpl_WriteBigBlock (storage32.c:3989) by BlockChainStream_GetBlockAtOffset (storage32.c:5951) by BlockChainStream_WriteAt (storage32.c:6198) by SmallBlockChainStream_WriteAt (storage32.c:6954) by StorageImpl_StreamWriteAt (storage32.c:2555) by StorageBaseImpl_StreamWriteAt (storage32.h:305) by StgStreamImpl_Write (stg_stream.c:286) by DataCacheEntry_Save (datacache.c:765) by DataCache_Save (datacache.c:1400) by test_data_cache (ole2.c:1411) by func_ole2 (ole2.c:1878) by run_test (test.h:556) by main (test.h:624) Address 0x7f03e6c0 is 504 bytes inside a block of size 8,260 alloc'd at notify_alloc (heap.c:254) by RtlAllocateHeap (heap.c:1701) by BlockChainStream_Construct (storage32.c:5972) by StorageImpl_Construct (storage32.c:2887) by Storage_Construct (storage32.c:5131) by create_storagefile (storage32.c:7347) by StgCreateDocfile (storage32.c:7408) by test_data_cache (ole2.c:1272) by func_ole2 (ole2.c:1878) by run_test (test.h:556) by main (test.h:624) 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 MFDRV_StretchBlt (bitblt.c:72) by StretchBlt (bitblt.c:174) by DrawIconEx (cursoricon.c:2008) by DrawIcon (cursoricon.c:1437) by OleMetafilePictFromIconAndLabel (ole32_main.c:108) by test_data_cache (ole2.c:1364) by func_ole2 (ole2.c:1878) by run_test (test.h:556) by main (test.h:624) ... 8 bytes in 1 blocks are possibly lost at notify_alloc (heap.c:254) by RtlAllocateHeap (heap.c:1701) by HeapAlloc (heap.c:267) by GlobalAlloc (heap.c:374) by DataObject_DAdvise (ole2.c:1163) by setup_sink (datacache.c:1884) by DataCache_OnRun (datacache.c:2085) by test_data_cache (ole2.c:1536) by func_ole2 (ole2.c:1878) by run_test (test.h:556) by main (test.h:624) ... 72 bytes in 1 blocks are possibly lost at notify_alloc (heap.c:254) by RtlAllocateHeap (heap.c:1701) by DataCache_Construct (datacache.c:2278) by CreateDataCache (datacache.c:2378) by DefaultHandler_Construct (defaulthandler.c:1951) by OleCreateEmbeddingHelper (defaulthandler.c:2110) by OleCreateDefaultHandler (defaulthandler.c:2137) by test_default_handler (ole2.c:1604) by func_ole2 (ole2.c:1879) by run_test (test.h:556) by main (test.h:624) ... 112 bytes in 1 blocks are possibly lost at notify_alloc (heap.c:254) by RtlAllocateHeap (heap.c:1701) by DefaultHandler_Construct (defaulthandler.c:1915) by OleCreateEmbeddingHelper (defaulthandler.c:2110) by OleCreateDefaultHandler (defaulthandler.c:2137) by test_default_handler (ole2.c:1604) by func_ole2 (ole2.c:1879) by run_test (test.h:556) by main (test.h:624) -- 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.

1 2

[Bug 26068] New: user32/dce tests shows a valgrind warning
by wine-bugs＠winehq.org 28 Sep '12

28 Sep '12

http://bugs.winehq.org/show_bug.cgi?id=26068 Summary: user32/dce tests shows a valgrind warning Product: Wine Version: 1.3.13 Platform: x86 OS/Version: Linux Status: NEW Keywords: download, source, testcase Severity: minor Priority: P2 Component: user32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: austinenglish(a)gmail.com Conditional jump or move depends on uninitialised value(s) at GDI_GetObjPtr (gdiobj.c:767) by get_dc_obj (dc.c:55) by get_dc_ptr (dc.c:181) by GetDCHook (dc.c:1415) by release_dc (painting.c:458) by ReleaseDC (painting.c:1078) by test_dc_attributes (dce.c:82) by func_dce (dce.c:559) by run_test (test.h:556) by main (test.h:624) Uninitialised value was created by a stack allocation at test_dc_attributes (dce.c:41) -- 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.

1 3

[Bug 16409] New: Ableton Live 7.0.12 crashes on startup
by wine-bugs＠winehq.org 28 Sep '12

28 Sep '12

http://bugs.winehq.org/show_bug.cgi?id=16409 Summary: Ableton Live 7.0.12 crashes on startup Product: Wine Version: 1.1.10 Platform: Other URL: http://www.ableton.com/pages/downloads/trial OS/Version: other Status: NEW Keywords: download Severity: normal Priority: P2 Component: directx-dsound AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com I saw this plea: http://www.kvraudio.com/forum/viewtopic.php?p=3286380 so I tried Ableton again, this time on Ubuntu Intrepid on my Compaq r3000. Sadly, it crashes on startup. In winedbg, the crash looks like this: First chance exception: page fault on read access to 0x00000000 in 32-bit code (0x7e4444a7). Backtrace: =>1 0x7e4444a7 IDirectSoundCaptureBufferImpl_GetCurrentPosition+0x1b7(iface=0x1b4648, lpdwCapturePosition=(nil), lpdwReadPosition=0x33f3c0) [dlls/dsound/capture.c:931] in dsound (0x0033f3a4) 2 0x00cdd628 in live 7.0.12 (+0x8dd628) (0x0033f3c4) ... 0x7e4444a7 IDirectSoundCaptureBufferImpl_GetCurrentPosition+0x1b7 [/home/dank/wine-git/dlls/dsound/capture.c:931] in dsound: movl 0x0(%eax),%ecx 931 pos = (DWORD_PTR)This->device->pwave[This->device->index].lpData - (DWORD_PTR)This->device->buffer; -- 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.

1 5

[Bug 26072] New: urlmon/protocol tests show some valgrind warnings
by wine-bugs＠winehq.org 28 Sep '12

28 Sep '12

http://bugs.winehq.org/show_bug.cgi?id=26072 Summary: urlmon/protocol tests show some valgrind warnings Product: Wine Version: 1.3.13 Platform: x86 OS/Version: Linux Status: NEW Keywords: download, source, testcase Severity: minor Priority: P2 Component: urlmon AssignedTo: wine-bugs(a)winehq.org ReportedBy: austinenglish(a)gmail.com Created an attachment (id=33247) --> (http://bugs.winehq.org/attachment.cgi?id=33247) valgrind log 2,048 bytes in 1 blocks are definitely lost at notify_alloc (heap.c:254) by RtlAllocateHeap (heap.c:1701) by heap_alloc (urlmon_main.h:225) by report_data (bindprot.c:1046) by BPInternetProtocolSink_ReportData (bindprot.c:1133) by ProtocolEmul_Continue (protocol.c:1764) by ProtocolHandler_Continue (bindprot.c:636) by BindProtocol_Continue (bindprot.c:386) by test_binding (protocol.c:3381) by func_protocol (protocol.c:3515) by run_test (test.h:556) by main (test.h:624) ... 8,080 bytes in 4 blocks are possibly lost at notify_alloc (heap.c:254) by RtlAllocateHeap (heap.c:1701) by get_tls_data (test.h:240) by winetest_set_location (test.h:275) by ProtocolSink_ReportProgress (protocol.c:773) by report_progress (bindprot.c:971) by BPInternetProtocolSink_ReportProgress (bindprot.c:1012) by thread_proc (protocol.c:1434) 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) and a few like: 48 (20 direct, 28 indirect) bytes in 1 blocks are definitely lost at malloc (vg_replace_malloc.c:236) by ??? by ??? by ??? by ??? by ??? by ??? by NETCON_init (netconnection.c:460) by HTTP_HttpOpenRequestW (http.c:2600) by HttpOpenRequestW (http.c:2730) by HttpProtocol_open_request (http.c:338) by protocol_start (protocol.c:278) by HttpProtocol_StartEx (http.c:750) by HttpProtocol_Start (http.c:647) by http_protocol_start (protocol.c:2653) by test_http_protocol_url (protocol.c:2783) by test_https_protocol (protocol.c:2927) by func_protocol (protocol.c:3495) by run_test (test.h:556) by main (test.h:624) -- 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.

1 2

[Bug 23876] New: Temporary Internet Files growing endless
by wine-bugs＠winehq.org 28 Sep '12

28 Sep '12

http://bugs.winehq.org/show_bug.cgi?id=23876 Summary: Temporary Internet Files growing endless Product: Wine Version: 1.3.0 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mshtml AssignedTo: wine-bugs(a)winehq.org ReportedBy: diafero(a)arcor.de It seems like applications using the embedded internet explorer will fill the Temporary Internet Files in my wine profile and make it grow endless: The game "Uru - The Path of the Shell" uses the embedded IE to download game updates. It runs perfectly fine in wine, but checking with a disk usage utility, I noticed that the Temporary Internet Files folder has a size of more than 600MB by now, containing a huge lot of the files that were downloaded by the updater (including the meta files with the update information that are downloaded on each startup - I had the same file in there more than 100 times). Obviously, the cache is not restricted by size as it is on windows. -- 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.

1 41

[Bug 26131] New: dsound/duplex tests show an uninitialized variable under valgrind
by wine-bugs＠winehq.org 28 Sep '12

28 Sep '12

http://bugs.winehq.org/show_bug.cgi?id=26131 Summary: dsound/duplex tests show an uninitialized variable under valgrind Product: Wine Version: 1.3.13 Platform: x86 OS/Version: Linux Status: NEW Keywords: download, source, testcase Severity: normal Priority: P2 Component: directx-dsound AssignedTo: wine-bugs(a)winehq.org ReportedBy: austinenglish(a)gmail.com Conditional jump or move depends on uninitialised value(s) at snd_pcm_mmap_begin (in /usr/lib/libasound.so.2.0.0) by CreateMMAP (dscapture.c:513) by IDsCaptureDriverBufferImpl_SetFormat (dscapture.c:737) by IDsCaptureDriverImpl_CreateCaptureBuffer (dscapture.c:1039) by IDirectSoundCaptureBufferImpl_Create (capture.c:935) by IDirectSoundCaptureImpl_CreateCaptureBuffer (capture.c:1256) by IDirectSoundFullDuplexImpl_Initialize (duplex.c:592) by DirectSoundFullDuplexCreate (duplex.c:737) by IDirectSoundFullDuplex_tests (duplex.c:184) by func_duplex (duplex.c:239) by run_test (test.h:556) by main (test.h:624) Uninitialised value was created by a stack allocation at CreateMMAP (dscapture.c:460) though perhaps that's an alsa bug? -- 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.

1 5

[Bug 26118] New: kernel32/change tests show a ton of valgrind warnings
by wine-bugs＠winehq.org 28 Sep '12

28 Sep '12

http://bugs.winehq.org/show_bug.cgi?id=26118 Summary: kernel32/change tests show a ton of valgrind warnings Product: Wine Version: 1.3.13 Platform: x86 OS/Version: Linux Status: NEW Keywords: download, source, testcase Severity: minor Priority: P2 Component: kernel32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: austinenglish(a)gmail.com Several uninitialized value warnings: Conditional jump or move depends on uninitialised value(s) at wine_dbgstr_wn (test.h:471) by wine_dbgstr_w (test.h:66) by test_readdirectorychanges_cr (change.c:860) by func_change (change.c:1103) by run_test (test.h:556) by main (test.h:624) Uninitialised value was created by a stack allocation at test_readdirectorychanges_cr (change.c:794) ... Conditional jump or move depends on uninitialised value(s) at wine_dbgstr_wn (test.h:471) by wine_dbgstr_w (test.h:66) by test_readdirectorychanges_cr (change.c:880) by func_change (change.c:1103) by run_test (test.h:556) by main (test.h:624) Uninitialised value was created by a stack allocation at test_readdirectorychanges_cr (change.c:794) ... Conditional jump or move depends on uninitialised value(s) at wine_dbgstr_wn (test.h:471) by wine_dbgstr_w (test.h:66) by test_readdirectorychanges_cr (change.c:896) by func_change (change.c:1103) by run_test (test.h:556) by main (test.h:624) Uninitialised value was created by a stack allocation at test_readdirectorychanges_cr (change.c:794) ... Conditional jump or move depends on uninitialised value(s) at wine_dbgstr_wn (test.h:471) by wine_dbgstr_w (test.h:66) by test_readdirectorychanges_cr (change.c:912) by func_change (change.c:1103) by run_test (test.h:556) by main (test.h:624) Uninitialised value was created by a stack allocation at test_readdirectorychanges_cr (change.c:794) ... Conditional jump or move depends on uninitialised value(s) at wine_dbgstr_wn (test.h:471) by wine_dbgstr_w (test.h:66) by test_readdirectorychanges_cr (change.c:944) by func_change (change.c:1103) by run_test (test.h:556) by main (test.h:624) Uninitialised value was created by a stack allocation at test_readdirectorychanges_cr (change.c:794) ... Conditional jump or move depends on uninitialised value(s) at wine_dbgstr_wn (test.h:471) by wine_dbgstr_w (test.h:66) by test_readdirectorychanges_cr (change.c:995) by func_change (change.c:1103) by run_test (test.h:556) by main (test.h:624) Uninitialised value was created by a stack allocation at test_readdirectorychanges_cr (change.c:794) ... and several leaks: 20 bytes in 1 blocks are definitely lost at notify_alloc (heap.c:254) by RtlAllocateHeap (heap.c:1701) by NtNotifyChangeDirectoryFile (directory.c:3253) by FindFirstChangeNotificationW (change.c:97) by FindFirstChangeNotificationA (change.c:49) by StartNotificationThread (change.c:65) by test_ffcn_directory_overlap (change.c:1033) by func_change (change.c:1104) by run_test (test.h:556) by main (test.h:624) ... 20 bytes in 1 blocks are definitely lost at notify_alloc (heap.c:254) by RtlAllocateHeap (heap.c:1701) by NtNotifyChangeDirectoryFile (directory.c:3253) by FindFirstChangeNotificationW (change.c:97) by FindFirstChangeNotificationA (change.c:49) by StartNotificationThread (change.c:65) by test_ffcn_directory_overlap (change.c:1035) by func_change (change.c:1104) by run_test (test.h:556) by main (test.h:624) ... 20 bytes in 1 blocks are definitely lost at notify_alloc (heap.c:254) by RtlAllocateHeap (heap.c:1701) by NtNotifyChangeDirectoryFile (directory.c:3253) by FindFirstChangeNotificationW (change.c:97) by FindFirstChangeNotificationA (change.c:49) by test_ffcn_directory_overlap (change.c:1054) by func_change (change.c:1104) by run_test (test.h:556) by main (test.h:624) ... 20 bytes in 1 blocks are definitely lost at notify_alloc (heap.c:254) by RtlAllocateHeap (heap.c:1701) by NtNotifyChangeDirectoryFile (directory.c:3253) by FindFirstChangeNotificationW (change.c:97) by FindFirstChangeNotificationA (change.c:49) by test_ffcn_directory_overlap (change.c:1058) by func_change (change.c:1104) by run_test (test.h:556) by main (test.h:624) ... 240 bytes in 12 blocks are definitely lost at notify_alloc (heap.c:254) by RtlAllocateHeap (heap.c:1701) by NtNotifyChangeDirectoryFile (directory.c:3253) by FindNextChangeNotification (change.c:118) by NotificationThread (change.c:50) 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) ... and one possibly lost: 28,280 bytes in 14 blocks are possibly lost at notify_alloc (heap.c:254) by RtlAllocateHeap (heap.c:1701) by get_tls_data (test.h:240) by winetest_set_location (test.h:275) by NotificationThread (change.c:54) 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) -- 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.

1 2

[Bug 26099] New: rpcrt4/ndr_marshal shows a ton of valgrind warnings
by wine-bugs＠winehq.org 28 Sep '12

28 Sep '12

http://bugs.winehq.org/show_bug.cgi?id=26099 Summary: rpcrt4/ndr_marshal shows a ton of valgrind warnings Product: Wine Version: 1.3.13 Platform: x86 OS/Version: Linux Status: NEW Keywords: download, source, testcase Severity: minor Priority: P2 Component: rpc AssignedTo: wine-bugs(a)winehq.org ReportedBy: austinenglish(a)gmail.com Created an attachment (id=33288) --> (http://bugs.winehq.org/attachment.cgi?id=33288) valgrind log 22 bytes in 1 blocks are definitely lost at notify_alloc (heap.c:254) by RtlAllocateHeap (heap.c:1701) by test_conformant_string (ndr_marshall.c:1545) by func_ndr_marshall (ndr_marshall.c:2419) 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 IMalloc_fnAlloc (ifs.c:186) by CoTaskMemAlloc (ifs.c:395) by NdrOleAllocate (ndr_ole.c:364) by my_alloc (ndr_marshall.c:42) by NdrAllocate (ndr_marshall.c:417) by NdrBaseTypeUnmarshall (ndr_marshall.c:6672) by PointerUnmarshall (ndr_marshall.c:965) by NdrPointerUnmarshall (ndr_marshall.c:1560) by test_pointer_marshal (ndr_marshall.c:278) by test_simple_types (ndr_marshall.c:473) by func_ndr_marshall (ndr_marshall.c:2411) by run_test (test.h:556) by main (test.h:624) (this one is there several times) ... 32 bytes in 1 blocks are definitely lost at notify_alloc (heap.c:254) by RtlAllocateHeap (heap.c:1701) by IMalloc_fnAlloc (ifs.c:186) by CoTaskMemAlloc (ifs.c:395) by NdrOleAllocate (ndr_ole.c:364) by my_alloc (ndr_marshall.c:42) by NdrAllocate (ndr_marshall.c:417) by NdrNonConformantStringUnmarshall (ndr_marshall.c:2623) by test_nonconformant_string (ndr_marshall.c:1678) by func_ndr_marshall (ndr_marshall.c:2420) by run_test (test.h:556) by main (test.h:624) ... 40 bytes in 1 blocks are definitely lost at notify_alloc (heap.c:254) by RtlAllocateHeap (heap.c:1701) by IMalloc_fnAlloc (ifs.c:186) by CoTaskMemAlloc (ifs.c:395) by NdrOleAllocate (ndr_ole.c:364) by my_alloc (ndr_marshall.c:42) by NdrAllocate (ndr_marshall.c:417) by NdrSimpleStructUnmarshall (ndr_marshall.c:1740) by test_simple_struct_marshal (ndr_marshall.c:830) by test_simple_struct (ndr_marshall.c:970) by func_ndr_marshall (ndr_marshall.c:2413) by run_test (test.h:556) by main (test.h:624) ... 40 bytes in 1 blocks are definitely lost at notify_alloc (heap.c:254) by RtlAllocateHeap (heap.c:1701) by IMalloc_fnAlloc (ifs.c:186) by CoTaskMemAlloc (ifs.c:395) by NdrOleAllocate (ndr_ole.c:364) by my_alloc (ndr_marshall.c:42) by NdrAllocate (ndr_marshall.c:417) by NdrSimpleStructUnmarshall (ndr_marshall.c:1740) by PointerUnmarshall (ndr_marshall.c:965) by NdrPointerUnmarshall (ndr_marshall.c:1560) by test_pointer_marshal (ndr_marshall.c:278) by test_simple_struct (ndr_marshall.c:977) by func_ndr_marshall (ndr_marshall.c:2413) by run_test (test.h:556) by main (test.h:624) ... 40 bytes in 1 blocks are definitely lost at notify_alloc (heap.c:254) by RtlAllocateHeap (heap.c:1701) by IMalloc_fnAlloc (ifs.c:186) by CoTaskMemAlloc (ifs.c:395) by NdrOleAllocate (ndr_ole.c:364) by my_alloc (ndr_marshall.c:42) by NdrAllocate (ndr_marshall.c:417) by test_ndr_allocate (ndr_marshall.c:1347) by func_ndr_marshall (ndr_marshall.c:2417) by run_test (test.h:556) by main (test.h:624) and a ton of possibly lost warnings, 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.

1 2

[Bug 26069] New: user32/clipboard tests shows a valgrind warning
by wine-bugs＠winehq.org 28 Sep '12

28 Sep '12

http://bugs.winehq.org/show_bug.cgi?id=26069 Summary: user32/clipboard tests shows a valgrind warning Product: Wine Version: 1.3.13 Platform: x86 OS/Version: Linux Status: NEW Keywords: download, source, testcase Severity: minor Priority: P2 Component: user32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: austinenglish(a)gmail.com 24 bytes in 3 blocks are definitely lost at notify_alloc (heap.c:254) by RtlAllocateHeap (heap.c:1701) by IMM_GetThreadData (imm.c:226) by ImmGetContext (imm.c:1366) by IME_UpdateAssociation (ime.c:1040) by open_xim (xim.c:477) by X11DRV_SetupXIM (xim.c:493) by x11drv_init_thread_data (x11drv_main.c:681) by thread_selection_wnd (clipboard.c:328) by selection_acquire (clipboard.c:2625) by selection_thread_proc (clipboard.c:2661) 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) -- 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.

1 2