What is the process for debugging Wine tests with GDB?
For instance, to debug the msxml3 tests I've tried tests $ gdb --args ../../../loader/wine64 msxml3_test.exe.so domdoc (gdb) b domdoc.c:13003 Make breakpoint pending on future shared library load? (y or [n]) y (gdb) r in which case gdb breaks at a segfault in which there is little stack information, but does not break at my breakpoint, as well as ... (gdb) set follow-fork-mode child (gdb) r in which case gdb still does not break at my breakpoint, nor at the segfault.
On 4/16/19 11:26 PM, Jefferson Carpenter wrote:
For instance, to debug the msxml3 tests I've tried
tests $ gdb --args ../../../loader/wine64 msxml3_test.exe.so domdoc (gdb) b domdoc.c:13003 Make breakpoint pending on future shared library load? (y or [n]) y (gdb) r
in which case gdb breaks at a segfault in which there is little stack information, but does not break at my breakpoint, as well as
... (gdb) set follow-fork-mode child (gdb) r
in which case gdb still does not break at my breakpoint, nor at the segfault.
The official answer is "use winedbg --gdb instead". Usually this works well enough. I've also run into some obscure edge cases, though, that have led me to try running wine under gdb instead. The big problem I've encountered is that the preloader bypasses ld and so prevents gdb from being able to load symbol information. This can be worked around by disabling the preloader. I then do (gdb) set detach-on-fork off (gdb) set schedule-multiple on (gdb) set print inferior-events on though I don't remember if/why all of these are necessary. That said, the crash in msxml3:domdoc is diagnosed to some degree; it happens because properties get double-freed. I looked at it once but didn't feel comfortable enough with msxml3 to attack it.
On Wed, Apr 17, 2019 at 3:00 AM Zebediah Figura <z.figura12(a)gmail.com> wrote:
The official answer is "use winedbg --gdb instead". Usually this works well enough.
I've also run into some obscure edge cases, though, that have led me to try running wine under gdb instead. The big problem I've encountered is that the preloader bypasses ld and so prevents gdb from being able to load symbol information. This can be worked around by disabling the preloader.
How does one run winedbg from the build tree? Running tests $ ../../../loader/wine64 winedbg msxml3_test.exe.so domdoc WineDbg starting on pid 002c couldn't load main module (2) 0x000000007bccc465: ret Wine-dbg> r couldn't load main module (2) 0x000000007bccc465: ret does not appear to allow me to debug with winedbg from the terminal. An empty command prompt window shows up (black with a blinking cursor, but no prompt). Then Wine-dbg> q runs all the tests, outputting stdout to the command prompt window as well as my terminal. How does one disable the preloader?
That said, the crash in msxml3:domdoc is diagnosed to some degree; it happens because properties get double-freed. I looked at it once but didn't feel comfortable enough with msxml3 to attack it.
Good to know, however if it's not being worked on I might as well see if I can fix it.
On 4/17/19 12:33 AM, Jefferson Carpenter wrote:
On Wed, Apr 17, 2019 at 3:00 AM Zebediah Figura <z.figura12(a)gmail.com> wrote:
The official answer is "use winedbg --gdb instead". Usually this works well enough.
I've also run into some obscure edge cases, though, that have led me to try running wine under gdb instead. The big problem I've encountered is that the preloader bypasses ld and so prevents gdb from being able to load symbol information. This can be worked around by disabling the preloader.
How does one run winedbg from the build tree? Running
tests $ ../../../loader/wine64 winedbg msxml3_test.exe.so domdoc WineDbg starting on pid 002c couldn't load main module (2) 0x000000007bccc465: ret Wine-dbg> r couldn't load main module (2) 0x000000007bccc465: ret
does not appear to allow me to debug with winedbg from the terminal. An empty command prompt window shows up (black with a blinking cursor, but no prompt). Then
Wine-dbg> q
runs all the tests, outputting stdout to the command prompt window as well as my terminal.
I don't know why that would happen; it works fine here. If you're using recent enough wine, you may have not msxml3_test.exe.so but msxml3_test.exe. Note that (1) you don't use 'r' with winedbg, and (2) you probably want to use the --gdb option, since bare winedbg does not work very well and has some arcane syntax in places.
On Wed, Apr 17, 2019 at 4:31 AM Zebediah Figura <z.figura12(a)gmail.com> wrote:
I don't know why that would happen; it works fine here. If you're using recent enough wine, you may have not msxml3_test.exe.so but msxml3_test.exe. Note that (1) you don't use 'r' with winedbg, and (2) you probably want to use the --gdb option, since bare winedbg does not work very well and has some arcane syntax in places.
Running tests $ ../../../loader/wine64 winedbg --gdb msxml3_test.exe.so domdoc 0025:err:plugplay:deviceloop_thread Can't init SDL: SDL not built with haptic (force feedback) support 002b:002c: create process 'Z:\home\rofl\wine64-build-debug\dlls\msxml3\tests\msxml3_test.exe'/0x10cb0 @0x7f61371143b1 (0<0>) 002b:002c: create thread I @0x7f61371143b1 the process exits immediately.
On 4/17/19 12:45 AM, Jefferson Carpenter wrote:
On Wed, Apr 17, 2019 at 5:33 AM Jefferson Carpenter <jeffersoncarpenter2(a)gmail.com> wrote:
How does one disable the preloader?
I can disable it by setting
use_preloader = 0;
in config.c but is there a more "official" way?
I don't know if there's an "official" way, but I guess the potentially easier way to do it is to clear the execute bit on wine-preloader.
participants (2)
-
Jefferson Carpenter -
Zebediah Figura