July 2012 - Wine-Bugs - list.winehq.org

[Bug 26286] New: Briscola Chiamata crashes on startup
by wine-bugs＠winehq.org Sept. 28, 2012

Sept. 28, 2012

http://bugs.winehq.org/show_bug.cgi?id=26286 Summary: Briscola Chiamata crashes on startup Product: Wine Version: 1.1.11 Platform: x86 URL: http://www.briscolachiamata.it/download/SetupBriscolaC hiamata.exe OS/Version: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: mshtml AssignedTo: wine-bugs(a)winehq.org ReportedBy: madewokherd(a)gmail.com Freeware game from: http://www.briscolachiamata.it/download.html This was originally affected by bug 7163, but the program has since been updated and the new version behaves differently. I'm leaving 7163 open for the old problem in case the old version is still available. The program installs fine, but when started it brings up a dialog that says "Abnormal program termination" and does nothing else. It appears to be crashing in mshtml/gecko code. Installing ie6 with winetricks allows the program to start and (from what little I can tell) run correctly. I tested this as far back as 1.1.11, in case it was introduced by new gecko, but it was present in that version. I'm using wine-1.3.14-238-ge572dca. -- 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 16409] New: Ableton Live 7.0.12 crashes on startup
by wine-bugs＠winehq.org Sept. 28, 2012

Sept. 28, 2012

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 Sept. 28, 2012

Sept. 28, 2012

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 Sept. 28, 2012

Sept. 28, 2012

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 Sept. 28, 2012

Sept. 28, 2012

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 Sept. 28, 2012

Sept. 28, 2012

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 Sept. 28, 2012

Sept. 28, 2012

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 26073] New: shell32/shelldispatch tests show some valgrind warnings
by wine-bugs＠winehq.org Sept. 28, 2012

Sept. 28, 2012

http://bugs.winehq.org/show_bug.cgi?id=26073 Summary: shell32/shelldispatch 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: shell32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: austinenglish(a)gmail.com Created an attachment (id=33248) --> (http://bugs.winehq.org/attachment.cgi?id=33248) valgrind log 32 bytes in 1 blocks are definitely lost at notify_alloc (heap.c:254) by RtlAllocateHeap (heap.c:1701) by Folder_Constructor (shelldispatch.c:712) by ShellDispatch_NameSpace (shelldispatch.c:854) by test_namespace (shelldispatch.c:87) by func_shelldispatch (shelldispatch.c:314) by run_test (test.h:556) by main (test.h:624) and a few possibly lost, like: 36 bytes in 1 blocks are possibly lost at notify_alloc (heap.c:254) by RtlAllocateHeap (heap.c:1701) by heap_alloc_zero (typelib.c:1471) by MSFT_DoRefType (typelib.c:2160) by ITypeLib2_Constructor_MSFT (typelib.c:3063) by TLB_ReadTypeLib (typelib.c:2822) by LoadTypeLibEx (typelib.c:435) by LoadTypeLib (typelib.c:411) by LoadRegTypeLib (typelib.c:494) by load_type_info (shelldispatch.c:82) by IShellDispatch_Constructor (shelldispatch.c:1052) by IDefClF_fnCreateInstance (shellole.c:467) by CoCreateInstance (compobj.c:2512) by test_namespace (shelldispatch.c:68) by func_shelldispatch (shelldispatch.c:314) by run_test (test.h:556) by main (test.h:624) I'll attach the full log. -- 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 Sept. 28, 2012

Sept. 28, 2012

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

[Bug 25947] New: dmime:performance tests shows some memory leaks under valgrind
by wine-bugs＠winehq.org Sept. 28, 2012

Sept. 28, 2012

http://bugs.winehq.org/show_bug.cgi?id=25947 Summary: dmime:performance tests shows some memory leaks under valgrind Product: Wine Version: 1.3.12 Platform: x86 OS/Version: Linux Status: NEW Keywords: download, source, testcase Severity: minor Priority: P2 Component: directx-dmusic AssignedTo: wine-bugs(a)winehq.org ReportedBy: austinenglish(a)gmail.com Created an attachment (id=33082) --> (http://bugs.winehq.org/attachment.cgi?id=33082) valgrind log 4 bytes in 1 blocks are definitely lost at notify_alloc (heap.c:254) by RtlAllocateHeap (heap.c:1701) by IDirectMusic8Impl_CreatePort (dmusic.c:142) by IDirectMusicPerformance8Impl_PChannelInfo (performance.c:599) by test_PChannelInfo (performance.c:46) by func_performance (performance.c:97) by run_test (test.h:556) by main (test.h:624) ... 12 bytes in 1 blocks are definitely lost at notify_alloc (heap.c:254) by RtlAllocateHeap (heap.c:1701) by IDirectSound8_IDirectSound8_Create (dsound.c:966) by DSOUND_Create8 (dsound.c:1090) by DirectSoundCreate8 (dsound.c:1141) by IDirectMusicPerformance8Impl_InitAudio (performance.c:761) by test_InitAudio (performance.c:35) by func_performance (performance.c:90) by run_test (test.h:556) by main (test.h:624) ... 144 bytes in 1 blocks are possibly lost at calloc (vg_replace_malloc.c:467) by _dl_allocate_tls (dl-tls.c:300) by pthread_create@@GLIBC_2.1 (allocatestack.c:431) by RtlCreateUserThread (thread.c:505) by CreateRemoteThread (thread.c:89) by CreateThread (thread.c:55) by TIME_MMTimeStart (time.c:260) by timeSetEvent (time.c:344) by DirectSoundDevice_Initialize (dsound.c:1487) by IDirectSound8_IDirectSound8_Initialize (dsound.c:920) by DirectSoundCreate8 (dsound.c:1143) by IDirectMusicPerformance8Impl_InitAudio (performance.c:761) by test_InitAudio (performance.c:35) by func_performance (performance.c:90) 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 3