On Tuesday, November 15, 2016 1:16:06 PM CET Andrew Eikum wrote:
That's a pretty broad question. You can grep a +relay log for the crashing pointer, it may show where that pointer was allocated which can help you identify useful debug channels. You could also search around for other pointers that appear nearby in the +relay log. You can try searching backwards from the crash for err: or warn: or fixme:, which may give a hint as to what's going wrong.
Do you get a useful backtrace? If not, I wrote a tool to indent +relay logs which can help you find what part of Wine is in use during the crash: https://gitlab.com/mywinetools/mywinetools/raw/master/nest.py
Andrew
Thanks for the reply, unfortunately it's a very broad question, since I don't know too much about what's going on. I'm looking for tricks I might now know, for example, not too long ago I didn't even know about using "+seh" to find a crash that the application processed itself.
The problem is that the backtrace isn't very useful, since the crash occurs in a function that is called a few thousand times per second. When nopped out, it resolves the crash while breaking collision handling in the game. But since the pointer is calculated from a lot of different values and passed around a lot, I find it hard to pin down where it comes from.
I'm currently debugging it with x64dbg which fortunately works very well under wine, but tracking dozens of different pointers to find out where they come from doesn't sound very effective to me.