Hi,
I use Libraw since some months in my app GraphicConverter 10 as optional RAW import.
I updated from the 0.18.x to version 0.19.
But the new version does crash if used in a background thread.
The crash occurs during initialization of the object:
LibRaw RawProcessor;
I attached a screenshot from the debugger.
Any help is appreciated.
Thorsten
| Attachment | Size |
|---|---|
 Screen Shot 2018-08-26 at 16.36.42.jpg | 70.33 KB |
Could you please provide more
Could you please provide more detailed bracktrace to see what line in LibRaw constructor caused that?
-- Alex Tutubalin @LibRaw LLC
There is very similar report
There is very similar report related to digiKam: https://github.com/LibRaw/LibRaw/issues/186
Quote from my last reply in that thread:
1st: the backtraces points to LibRaw::LibRaw (constructor), so the problem is not related to any specific RAW file
2nd: I've tried XCode 6, XCode 8, XCode 9 builds (using make -f Makefile.dist) and was unable to reproduce the problem using both dcraw_emu (single thread) and half_mt (multithreaded). Both samples works fine with DSC_1796.NEF sample (link above). The sample was multiplied into many (same) files: DSC_1796-[0-9].NEF
So, I'm still suspect that this is not LibRaw problem, but not enough stack problem. LibRaw objects are big (e.g. several 16-bit curves), so default stack size could be not enough (it is better to allocate LibRaw object dynamically to avoid that).
Is there any way to see is enough stack space is present [in your app]?
-- Alex Tutubalin @LibRaw LLC
Solved
It was a stack problem. The memory footprint must have changed from 0.18.x to 0.19.
So, please close the issue.
Thank you for confirming that
Thank you for confirming that.
Yes, LibRaw(0.19) object is significantly larger than (0.18). Looks like we need to move curve[0x1000] to dynamic allocation to save stack.
-- Alex Tutubalin @LibRaw LLC