I'm currently trying to get a program to work that doesn't work with wine, causing an access-violation at some unreadable address.
The "+seh" output shows that it's the first crash, and "+relay" doesn't help much, since the last calls are "user32.GetKeyState" and similar. I already tried debugging the program, but at the place of the crash there aren't any wine functions called, so I assume it's some earlier parts (e.g. during loading) causing the issue.
How do I go about finding which wine functions are the culprit? Any tips for that, how do you investigate such issues? It would be easy if it crashed directly after calling a WinApi function, but since it seems to crash much later in a completely different part of the code, I don't really know how to proceed.
On Mon, Nov 14, 2016 at 11:58:43PM +0100, Fabian Maurer wrote:
I'm currently trying to get a program to work that doesn't work with wine, causing an access-violation at some unreadable address.
The "+seh" output shows that it's the first crash, and "+relay" doesn't help much, since the last calls are "user32.GetKeyState" and similar. I already tried debugging the program, but at the place of the crash there aren't any wine functions called, so I assume it's some earlier parts (e.g. during loading) causing the issue.
How do I go about finding which wine functions are the culprit? Any tips for that, how do you investigate such issues? It would be easy if it crashed directly after calling a WinApi function, but since it seems to crash much later in a completely different part of the code, I don't really know how to proceed.
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
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.
-
Andrew Eikum -
Fabian Maurer