On 12/23/2011 09:56 PM, Ken Thomases wrote:
On Dec 23, 2011, at 3:10 PM, Michael Ost wrote:
This all makes sense, and pulls the code together for me. Thanks!
You're welcome.
I assume this is a recent development, because I was successfully using gdb
with our last wine version - 1.1.7.
Nope. This is how it has worked for a long, long time. Don't know what else
has changed. Maybe some of the other work on the DIB engine has changed
whether/when the DIB accesses cause access violations that you're seeing.
Interesting. Maybe a resource that is loaded at startup changed so it
needs alpha blending now. I'll see if I can hack around that for my
local use with gdb.
Thanks again,
Michael Ost
But it no longer sounds workable to use gdb for debugging winelib applications,
which is a drag. Are you suggesting using winedbg instead?
Well, you can use winedbg with $BreakOnFirstChance set to 0, for some apps.
(Setting $BreakOnFirstChance to 0 only has to be done once for a given
WINEPREFIX. It's saved in the registry.)
You can also try that "handle SIGSEGV nostop noprint pass" command I gave you. You might
try starting with that signal-handling setup and then, when you get close to where you expect a
true crash to happen, switch it back ("handle SIGSEGV stop print nopass").
Some day, the DIB engine will be complete and this memory protection scheme
will not be necessary to coordinate DIB access between memory and the X server.
Do you know if it can be used as a drop-in replacement in, say, Qt Creator
(which is my IDE of choice)?
No, it can't. Its interface is not identical to gdb's.
Regards,
Ken
