On 12/22/11 8:20 PM, Ken Thomases wrote:
On Dec 22, 2011, at 8:14 PM, Vitaliy Margolen wrote:
On 12/22/2011 04:45 PM, Michael Ost wrote:
I'm seeing a SEGV crash when running any wine program with wine 1.3.24 in
gdb but not when running without the debugger. The crash is happening when
writing to memory allocated by CreateDIBSection in the function
create_alpha_bitmap(). The code is in user32/cursoricon.c.
This is not a crash, this is the way it supposed to work. At least until DIB is
finished and this hack isn't needed.
Wine uses this trick to detect when DIB memory needs to be synchronized with
the X server.
To elaborate:
With the debugger on, writing to ptr[0] causes the segfault. And, indeed, when
I look at /proc/PID/maps for the problem address (0x350000) it is read only.
Without the debugger, the memory is read-write and the calls work.
The memory is not read-write, at least not at first. Wine handles the SEGV by
reading the image back from the X server and making the memory read-write. If
and when the app uses GDI to draw to the DIB, then the memory will be made
read-only again and the image will be uploaded to the X server before X
graphics operations are performed on it.
But under gdb the exception handler is not called. The memory is not unlocked
and the SEGV happens.
You have the order of operations the wrong way around. The memory access is attempted.
The SEGV is generated ("happens"), whether or not gdb is attached. Gdb, being
a debugger, stops the process when most signals are raised, to give the programmer an
opportunity to investigate.
If you were to tell gdb to deliver the signal and let the process proceed, using the
command "signal SIGSEGV", Wine's signal handler would be invoked and would do
the appropriate thing. This will be extremely tedious, though, since DIB accesses can
happen a lot.
You can tell gdb to ignore the SEGV using a command like "handle SIGSEGV nostop noprint pass".
Unfortunately, that will prevent you from debugging SEGVs other than DIB access. (It also doesn't extract
the debugger entirely from the signal handling, making DIB operations somewhat slower than normal, but that
can't really be avoided.) This is where winedbg's "set $BreakOnFirstChance=0" can be very
valuable. It doesn't help with gdb, though, and it also doesn't help for those applications which use
exception handlers to die "gracefully" rather than crashing.
This all makes sense, and pulls the code together for me. Thanks!
I assume this is a recent development, because I was successfully using
gdb with our last wine version - 1.1.7.
But it no longer sounds workable to use gdb for debugging winelib
applications, which is a drag. Are you suggesting using winedbg instead?
Do you know if it can be used as a drop-in replacement in, say, Qt
Creator (which is my IDE of choice)?
-- Michael Ost
