Consistenly crashing on MacOS 10.14 whether hosted in Krita or Gimp
ShirtlessWebmaster opened this issue · 15 comments
I am big fan of the G'Mic filters and they have become an integral part of my idea generation process. A big thanks to anyone contributing to this brilliant and inspiring tool.
I am struggling to find a way of hosting the GUI of Gmic on MacOS. In both Krita or GIMP the plug-in consistently crashes after a few moves. Somebody over on Reddit suggested I posted my crash logs to here, so here goes. Let me know if there's anything else I can do to provide useful information.
And here's a crashlog from Krita crashing on my laptop also running MacOS 10.14
krita macos (10.14) crashlog laptop.txt
.
Thanks for your report.
We don't have a Mac, so we'll have a hard time being useful here.
Anyway, I remember that for years, we got frequent G'MIC crashes in the past on MacOS, with frequent reports by @karo11 .
After years of investigation, we found out it was due to the fact that on MacOS, the default stack size allocated for a new thread is ridiculously low (512 KB by default), and that it was not enough for the G'MIC commands running with multi-threading.
Your log suggests it could be related (I see multiple threads trying to run there).
That particularly why we have this hack in file gmic.cpp: https://github.com/GreycLab/gmic/blob/master/src/gmic.cpp#L10765
where we try forcing the stack size of a new thread to be 8 Mo (which is actually the default size for Linux systems, where everything runs fine :) ).
But that hack is done for the moment only for threads that are created by the G'MIC interpreter itself, not threads that could be created by the G'MIC-Qt plug-in or by Krita.
I think G'MIC-Qt also creates threads (@c-koi may confirm), so it may be necessary to apply the same kind of hack for those threads too. This also applies for possible threads created by Krita (@amyspark may confirm).
That's my take on the subject.
On MacOSX, the default stack size for the main thread is actually 8Mo while the stack size of a newly created thread is 512KB.
My guess is that if the G'MIC interpreter is instanciated in a thread that is not the main thread, then it has to work with 512KB of stack size, which is (obviously :) ) not enough, so it will crash.
I think this is the caller's responsibility (G'MIC-Qt or Krita) to ensure enough stack size to the new thread for the task to be done correctly. I'm not sure it's even possible to change the stack size of a thread when the thread has started.
As for Krita, we already run a 16MB stack for G'MIC and Krita itself-- see https://github.com/amyspark/gmic/blob/8a6ce71ddc868400eb25676f51c43bd014e0e33d/gmic-qt/CMakeLists.txt#L255-L267, so that can be safely excluded.
It's lovely to hear some background information and knowing the issue has been researched in the past. If there's anything I could try regarding the gmic.cpp-hack I'd be able to do it with specific instructions on which files to alter on my system.
As for Krita, we already run a 16MB stack for G'MIC and Krita itself-- see https://github.com/amyspark/gmic/blob/8a6ce71ddc868400eb25676f51c43bd014e0e33d/gmic-qt/CMakeLists.txt#L255-L267, so that can be safely excluded.
But that is only for Windows, not for MacOS, right?
But that is only for Windows, not for MacOS, right?
facepalms Oh my, yes. I'll fix it on our end.
I've had some time to review this on our end. macOS is indeed not covered by our workaround, but that wouldn't have affected the worker threads as detailed in 1. G'MIC already works around this in https://github.com/GreycLab/gmic/blob/master/src/gmic.cpp#L10779.
Now that I had a closer look at that call stack, I've had one such report before which I couldn't reproduce. What filter were you running when the crash happened, and what was the image size?
G'MIC already works around this in https://github.com/GreycLab/gmic/blob/master/src/gmic.cpp#L10779.
Except that if your Krita-specific code launches the G'MIC interpreter in its own thread ?
I don't know if this is the case or not.
(And thanks for your postcard, I've received it today :) ).
Except that if your Krita-specific code launches the G'MIC interpreter in its own thread ?
As with every plugin, yes. But the crashing thread is a separate worker thread, which falls under your code's purview.