Question regarding ExcHndl and stack overflows

[Isopod]

Hi,

I've recently been trying to help out the GIMP project with some problems on Windows. I've learned that GIMP uses ExcHndl to produce stack traces automatically, but occasionally they get bug reports for crashes that don't leave any stack trace at all. I've recently been dealing with one of those issues (https://gitlab.gnome.org/GNOME/gimp/-/issues/13576) and it's difficult since I can't reproduce it locally and the affected users can't provide a stack trace.

I don't know all the details of how the structured exception handling machinery on Windows works under the hood and researching this would take quite a bit of time, so I figured it would be more efficient to just ask:

I've had this theory that those types of crashes might be caused by stack overflows as a result of infinite recursion. I suspect that in that case there would not even be enough stack space left to run the crash handler. At least I don't see how it would work, but again, I'm not familiar with the details. Could this be the case or is this just not how it works?

If the theory is correct, would it be possible to work around this somehow, e.g. by allocating a special stack just for exception handling, or running the exception handler in a different thread etc.? Do you have any other ideas why there might be no stack trace?

Thanks

[jrfonseca]

Hi,

My first recommendation in such case would be to ask your user to download drmingw latest binaries and then run gimp through catchsegv like

catchsegv.exe -m path\to\gimp.exe  > output.log 2>&1

And if this doesn't work do

catchsegv.exe -m -1 path\to\gimp.exe  > output.log 2>&1

so even first chance of exceptions get logged.

catchsegv works like exchndl, but is a debugger -- a separate process with its own stack.

Handling stack overflow in-process is not impossible but finicky:

• If one mucks about with the stack segment -- for example, allocate many of guard pages at the end, and then mark all pages as read/write when stack overflow happens -- one might be able to handle stack overflow -- but this requires one to control how all threads are created.
• Switching CPU context might work too, but that's difficult to achieve without hand written assembly.
• Another solution would be for exchndl to invoke an external process like catchsegv.exe on stack overflow. Or at least a separate thread for the processing exceptions like you said.

But whatever one does, is always going to be difficult to get right and still brittle. Hence a 100% external solution like catchsegv.exe should be more reliable IMO.