[Bug 51484] New: dmloader:loader fails randomly with a DMUS_E_LOADER_BADPATH error
https://bugs.winehq.org/show_bug.cgi?id=51484 Bug ID: 51484 Summary: dmloader:loader fails randomly with a DMUS_E_LOADER_BADPATH error Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: directx-dmusic Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Created attachment 70320 --> https://bugs.winehq.org/attachment.cgi?id=70320 Unsuccessful attempt to more reliably reproduce the failure dmloader:loader fails randomly in test_directory(): https://test.winehq.org/data/patterns.html loader.c:105: Test failed: SetSearchDirectory failed with 0x88781181 loader.c:107: Test failed: SetSearchDirectory failed with 0x88781181 where 0x88781181 == DMUS_E_LOADER_BADPATH. As of writing only w7u and cw-gtx560-1506 had failures but they are quite rare (up to 110 runs between failures), so maybe the other platforms just got lucky. Also once (2021-06-21) there was this set of failures: loader.c:105: Test failed: SetSearchDirectory failed with 0x88781181 loader.c:107: Test failed: SetSearchDirectory failed with 0 So it's as if there was a race condition causing SetSearchDirectory() to fail until some initialization process completed. That or it's some sort of uninitialized memory issue and the failures truly are random; or SetSearchDirectory() checks the presence of some directory corresponding to "", and some other process interferes with that. The attached patch has no success reproducing this issue so maybe the cause is external. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=51484 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase -- 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.
https://bugs.winehq.org/show_bug.cgi?id=51484 Michael Stefaniuc <mstefani(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mstefani(a)winehq.org --- Comment #1 from Michael Stefaniuc <mstefani(a)winehq.org> --- Created attachment 73217 --> https://bugs.winehq.org/attachment.cgi?id=73217 Check if GetCurrentDirectory got corrupt Another attempt at trying to see what got corrupted. Though I doubt this will show anything as setting the path from GetCurrentDirectory a few lines above has never failed... -- 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.
https://bugs.winehq.org/show_bug.cgi?id=51484 mrdeathjr28(a)yahoo.es changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mrdeathjr28(a)yahoo.es -- 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.
https://bugs.winehq.org/show_bug.cgi?id=51484 --- Comment #2 from François Gouget <fgouget(a)codeweavers.com> --- Maybe the right approach is to try to fix the crash in Wine (though it may not be much easier to reproduce), and hope it's some sort of memory corruption that's also responsible for the failures on Windows 7. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=51484 --- Comment #3 from Michael Stefaniuc <mstefani(a)winehq.org> --- Sure, but is it actually crashing in dmloader? I'm confused about the "03f0:loader: 104 tests executed (0 marked as todo, 0 as flaky, 0 failures), 0 skipped. dmloader:loader:03f0 done (-1073741819) in 0s 88B" https://test.winehq.org/data/e3f00bf7c944f1cde6151fde969f2b49649c3de7/linux_... or "0564:loader: 104 tests executed (0 marked as todo, 0 as flaky, 0 failures), 0 skipped. dmloader:loader:0564 done (258) in 120s 88B" from https://test.winehq.org/data/81a6c8c882e9d00a3f459983d8281327f25e333a/linux_... The "104 tests executed (0 marked as todo, 0 as flaky, 0 failures), 0 skipped." matches what we have in a successful run e.g. https://test.winehq.org/data/81a6c8c882e9d00a3f459983d8281327f25e333a/linux_... But yeah, I'll need to see if I can run it under valgrind and get something useful out of 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.
https://bugs.winehq.org/show_bug.cgi?id=51484 --- Comment #4 from François Gouget <fgouget(a)codeweavers.com> --- I expect that to mean that the executable crashes on exit, maybe because of memory / stack corruption. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=51484 --- Comment #5 from François Gouget <fgouget(a)codeweavers.com> --- Created attachment 73908 --> https://bugs.winehq.org/attachment.cgi?id=73908 Comment out all non-essential parts to reproduce the crash in Wine Running this test with WINEDEBUG=heap makes the crash on exit almost systematically reproducible. From that I found that test_simple_playing() is to blame and more specifically the code up to the rifffile IDirectMusicLoader8_GetObject() call. See the attached patch for details. Here are the traces I get with that patch: 0418:trace:heap:RtlAllocateHeap handle 01B70000, flags 0, size 0x8a, return 01B71CB0, status 0. 0418:err:sync:RtlLeaveCriticalSection section 00140074 "dlls/ntdll/heap.c: main process heap section" is not acquired ... 0418:trace:heap:RtlAllocateHeap handle 00140000, flags 0, size 0x20, return 00193BE0, status 0. 0418:err:sync:RtlLeaveCriticalSection section 00140074 "dlls/ntdll/heap.c: main process heap section" is not acquired ... 0418:trace:heap:RtlFreeHeap handle 00140000, flags 0, ptr 00157A30, return 1, status 0. 0418:err:sync:RtlLeaveCriticalSection section 00140074 "dlls/ntdll/heap.c: main process heap section" is not acquired 0418:trace:heap:RtlFreeHeap handle 00140000, flags 0, ptr 00157A68, return 1, status 0. 0418:err:sync:RtlLeaveCriticalSection section 00140074 "dlls/ntdll/heap.c: main process heap section" is not acquired ... 0418:trace:heap:RtlFreeHeap handle 00140000, flags 0, ptr 00157DE8, return 1, status 0. 0418:err:sync:RtlLeaveCriticalSection section 00140074 "dlls/ntdll/heap.c: main process heap section" is not acquired ... 0418:trace:heap:RtlFreeHeap handle 00140000, flags 0, ptr 00158210, return 1, status 0. 0418:err:heap:validate_free_block heap 00140000, block 00194D90: invalid next block back pointer ... right after the dump ... 0418:err:sync:RtlLeaveCriticalSection section 00140074 "dlls/ntdll/heap.c: main process heap section" is not acquired ... right after one more dump ... 0430:err:virtual:virtual_setup_exception stack overflow 900 bytes addr 0x7bc56a8d stack 0x1e90c7c (0x1e90000-0x1e91000-0x2090000) I think it's that stack overflow that causes the crash on exit. However it's likely caused by the previous heap trouble. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=51484 --- Comment #7 from Michael Stefaniuc <mstefani(a)winehq.org> --- To follow up on my previous comment: I get the both +heap errors until I comment out the IDirectMusicPerformance8_InitAudio() call. We have that call in two other test files: - dlls/dmime/tests/dmime.c - dlls/dmime/tests/performance.c The later has at least one IDirectMusicPerformance8_InitAudio() call with the exact same parameters passed to it like in the loader test. Running those two tests with +heap I do see the the error err:sync:RtlLeaveCriticalSection main process heap section" is not acquired But not the err:heap:validate_free_block, nor crashes. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=51484 --- Comment #6 from Michael Stefaniuc <mstefani(a)winehq.org> --- I can confirm that test_simple_playing() is the culprit. Commenting that one out makes both the: - err:sync:RtlLeaveCriticalSection main process heap section" is not acquired - err:heap:validate_free_block heap invalid next block back pointer errors go away and no crashes. But the issue is prior to rifffile. Commenting the function out from the riffile use to the end of the function still produces the +heap errors with subsequent crash. I guess that's what you meant but it wasn't clear to me. -- 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.
participants (1)
-
WineHQ Bugzilla