https://bugs.winehq.org/show_bug.cgi?id=50842
Bug ID: 50842 Summary: The 64-bit msado15:msado15 test crashes Product: Wine Version: 6.3 Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: fgouget@codeweavers.com
The 64-bit msado15:msado15 test crashes on all Windows versions: https://test.winehq.org/data/tests/msado15:msado15.html
msado15.c:626: this is the last test seen before the exception 090c:msado15: unhandled exception c0000005 at 0000000000408607
So the crash happens either during the test_ADORecordsetConstruction() cleanup, or the initialization of test_ConnectionPoint().
This failure is new because WineTest was incorrectly skipping the msado15:* tests before.
https://bugs.winehq.org/show_bug.cgi?id=50842
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase
https://bugs.winehq.org/show_bug.cgi?id=50842
Bernhard Übelacker bernhardu@mailbox.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu@mailbox.org
--- Comment #1 from Bernhard Übelacker bernhardu@mailbox.org --- Created attachment 71355 --> https://bugs.winehq.org/attachment.cgi?id=71355 rr-debugging of testbot executable with wine
Hello François, I tried to reproduce this with an patch with just a few extra traces, but that did not show the crash. https://testbot.winehq.org/JobDetails.pl?Key=104228
So I downloaded the winetest64-latest.exe from the last batch test run, extracted msado15_test.exe and with this the crash is reproducible on testbot. Unfortunately those executables have the debug information stripped.
But still I wondered if the crashing address shown might be inside the test executable image itself. Therefore I tried to debug it inside wine setting the breakpoint to 0x408817 and it stopped: => 0x408817: mov (%rcx),%rax
And running backwards it seems this value in $rcx got created in wine by CoCreateInstance at msado15.c:596 and is finally the value of the variable recordset.
So one theory might be that the variable recordset gets overwritten later.
But is there a way to submit jobs to testbot, so they will run through winetest64-latest.exe, like in the batch runs?
https://bugs.winehq.org/show_bug.cgi?id=50842
--- Comment #2 from François Gouget fgouget@codeweavers.com --- To run the test through WineTest, upload winetest64-latest.exe and specify the following arguments:
-c -o - -t foo msado15:msado15
Note however that '-o -' requires a WineTest patch: otherwise it will just send the test's output to a file called '-' which the TestBot will not retrieve.
https://www.winehq.org/pipermail/wine-devel/2021-December/203498.html
Also if using this trick on a Wine machine and the executable is called 'winetest.exe', Wine will run 'programs/winetest/winetest.exe' instead of your uploaded executable because winetest.exe is a builtin :-( The workaround is to use any name that does not match a Wine builtin.
https://bugs.winehq.org/show_bug.cgi?id=50842
--- Comment #3 from Bernhard Übelacker bernhardu@mailbox.org --- Thanks, works great: https://testbot.winehq.org/JobDetails.pl?Key=104251
But I fear this issue depends also from the toolchain used, and I hoped there would be a way to have testbot build such a winetest64-latest.exe by itself. This building machine is currently a Debian 11 Bullseye? Because my sample from a Debian testing/Bookworm does not show this crash.
https://bugs.winehq.org/show_bug.cgi?id=50842
--- Comment #4 from François Gouget fgouget@codeweavers.com --- The official WineTest executables are built by Alexandre, not by the TestBot. So I have no idea about the toolchain that's used.
https://bugs.winehq.org/show_bug.cgi?id=50842
Robert Wilhelm sloper42@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sloper42@yahoo.com
--- Comment #5 from Robert Wilhelm sloper42@yahoo.com --- Created attachment 71360 --> https://bugs.winehq.org/attachment.cgi?id=71360 Dr. Memory log running official msado15_test.exe on W11 VM
https://bugs.winehq.org/show_bug.cgi?id=50842
--- Comment #6 from Robert Wilhelm sloper42@yahoo.com --- Created attachment 71361 --> https://bugs.winehq.org/attachment.cgi?id=71361 Output of test run.
Looks like official test exe was compiled on debian 10 buster.
https://bugs.winehq.org/show_bug.cgi?id=50842
--- Comment #7 from Bernhard Übelacker bernhardu@mailbox.org --- @Robert: thanks for the tip with the test logfile - I have successfuly overlooked this header. I just found by strings in the executable an "GCC: (GNU) 8.3-win32 20190406", but that alone made it not certain it is a Debian.
I fear the drmemory log could potentially reveal information about the native implementation. Therefore will I not look into it until told otherwise. I guess this is also the reason, why e.g. no backtrace is shown in crashing test runs at windows. Maybe you want to mark this file as outdated or someone removes it, if I am right.
Inside a Buster VM I could rebuild the crashing winetest executable: https://testbot.winehq.org/JobDetails.pl?Key=104290
And added a few trace lines here, which confirms my theory that variable recordset gets overwritten: https://testbot.winehq.org/JobDetails.pl?Key=104291
Somewhere in this function call: 647 hr = Field_get_DefinedSize( field, &size );
And these test runs show that the variables size is just before recordset in memory: https://testbot.winehq.org/JobDetails.pl?Key=104299 https://testbot.winehq.org/JobDetails.pl?Key=104300
Following should show if native writes more than 4 bytes: https://testbot.winehq.org/JobDetails.pl?Key=104301 (But unfortunately currently delayed by the batch runs ...)
https://bugs.winehq.org/show_bug.cgi?id=50842
Robert Wilhelm sloper42@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #71360|0 |1 is obsolete| |
https://bugs.winehq.org/show_bug.cgi?id=50842
--- Comment #8 from Robert Wilhelm sloper42@yahoo.com --- @Bernhard: No useful information for you in the log.
drmemory log only confirms what you already pointed out in comment 1: null pointer access in mov (%rcx),%rax with stacktrace completely in msado15_test.exe. It does not give any hints where the variable got overwritten.
https://bugs.winehq.org/show_bug.cgi?id=50842
--- Comment #9 from Bernhard Übelacker bernhardu@mailbox.org --- Submitted patch: https://www.winehq.org/pipermail/wine-devel/2021-December/thread.html#203669
https://bugs.winehq.org/show_bug.cgi?id=50842
--- Comment #10 from Bernhard Übelacker bernhardu@mailbox.org --- Seems it got fixed by commit: https://source.winehq.org/git/wine.git/commitdiff/1bf3ebdfc4b7f7ec7c0506392e...
https://bugs.winehq.org/show_bug.cgi?id=50842
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |1bf3ebdfc4b7f7ec7c0506392ec | |3e67e245c2e62 Resolution|--- |FIXED Status|NEW |RESOLVED
--- Comment #11 from Hans Leidekker hans@meelstraat.net --- Fixed by 1bf3ebdfc4b7f7ec7c0506392ec3e67e245c2e62.
https://bugs.winehq.org/show_bug.cgi?id=50842
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #12 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 7.2.
https://bugs.winehq.org/show_bug.cgi?id=50842
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |7.0.x
https://bugs.winehq.org/show_bug.cgi?id=50842
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|7.0.x |---
--- Comment #13 from Michael Stefaniuc mstefani@winehq.org --- Drop 7.0.x target milestone from bugs that didn't make it.