What is the process for debugging Wine tests with GDB?

Zebediah Figura z.figura12 at gmail.com
Tue Apr 16 21:59:43 CDT 2019


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.



More information about the wine-devel mailing list