search

jrfonseca / drmingw

Postmortem debugging tools for MinGW.
GNU Lesser General Public License v2.1
273 stars 53 forks source link

Have it handle stack corruption #59

Closed Zero3K closed 2 years ago

Zero3K commented 2 years ago

It would be nice if it could handle stack corruption so it shows the function responsible for a crash instead of nothing.

jrfonseca commented 2 years ago

It depends how the stack is corrupted.

DrMinGW should always show the address of the function where a crash happened.

But if the stack is corrupted, then the IP register address might also become corrupted (e.g, when a function returns and pops garbagge return address.) If that's what's happening, then there's really nothing DrMinGW can do...

If you can paste DrMinGW's output that would help to understand.

Zero3K commented 2 years ago

image

jrfonseca commented 2 years ago

Stack back trace looks reasonable. IIUC, this is https://github.com/Zero3K/hpsx64, a Playstation 1 emulator you're working on. I suppose the 000001D985850000 address range is JIT x86 code, dynamically translated from Playstation's CPU code, right?

DrMinGW will never be able to deal with JIT x86 code perfectly, as there is no debugging information for that.

If you ensure your dynamically generated x86 code always setups frame pointer (RBP), that will help DrMinGW to unwind the stack. But it will won't know anything about these functions.

For such especiallized applications which deal with lots of x86 dynamic code, my recomendation would be to catch the exception in-process, and walk the stack yourself. You can still use MgwHelp DLL to help you resolve MinGW symbols though, but you'd need to look up JIT code yourself.

I hope this helps / makes sense.