Do you have any example of filters that crash when used in the gimp plug-in?
I don’t know. Maybe Karsten could help. Probably all parallelized filters (like the Smoothing filters in ‘Repair/’) have problems.
Hi, I have actually the problem that I don’t get a crash of the plugin! So normally switching Parallel on produces them.
Still I am supiscious that parallelization is not enabled although I have set the flag.My activity dont show it!
This is a build from git (1653_pre) compiled with the native compiler (10.10.5)!
The cli still crashes always with -x_hough (bus error 10) and that happens with Custom code “-x_hough” in the plugin too. Maybe by other reasons! I have display enabled too in the plugin!
The smoothing filters produce timeouts, if that could be switched off crashes probably appear again.
I have now tried “-demo 1” via the custom command in Gimp. Demo works in parallel but my mac does not take more than 110% cpu for the plugin! Several animations are quite slow (2fps). That is not normal
Karsten
Crashes are indeed really random… in my case, -x_hough seems to work fine in the cli if I do not pass any external image (in which case an internally generated image is used), while it crashes with an external one. In other words,
./gmic -x_hough
is ok while
./gmic image.jpg -x_hough
fails.
By the way, what do you exactly mean when you say “switch parallelisation on”?
Is it -Dgmic_is_parallel or -Dcimg_use_openmp or both? I’m only setting the first flag for the moment.
My personal feeling is that the troubles start when gmic calls itself (i.e. nested calls to gmic::_run()). I have started to play with the freaky details filter, and again
./gmic picture.jpg -_gimp_freaky_details 2,10,1, -output out.jpg
works fine while
./gmic picture.jpg -gimp_freaky_details 2,10,1,1,2,1 -output out.jpg
fails with a segfault. If I’m not wrong, the second call uses a single thread, but goes through the -gimp_parallel_overlap function, isn’t it?
Would it be possible to “simplify” the freaky details filter (for example removing the -repeat commands)? Just to see at which point things become unstable…
Hi, I don’t use openmp, since the apple g++ don’t support it. I have tried it with the macports clang 3.7 but that was no improvement. Since my public build of the plugin should not need extra libraries beside GIMP I stay with the apple compiler. For the cli everything is possible, still I have tried there beside MacPorts the compilers from High Performance Computing for Mac OS X http://hpc.sourceforge.net/ and from François-Xavier Coudert http://coudert.name/ without any improvement.
As you say, it is in a certain way random. At least crashes are stable!
Karsten
Ok, I’m also using the default clang from Xcode, not using macports or homebrew but compiling everything myself with jhbuild. So our environments should be quite similar.
However, in this case in order to force the parallel computing with the CLI one has to go through -gimp_parallel_overlap, right? Except maybe for the demos, which I don’t know very well…
On my machine both calls work flawless!
I am using the “-demo 1” and "-parallel “cmd”,“cmd1"” or on several images “-apply_parallel “cmd””.
Hi all!
I’m beginning to believe that at least part of the issues are related to the -local command.
I’ve been playing with the freaky details filter, trying to make it more and more simple (although at some point not really meaningful, but for testing that’s OK).
Here is what I have at the moment:
_gimp_freaky_details2 :
[-1] ---[-1] 255 -*[-1] -1
-bilateral[-1] $2,{1.5*$2}
#-blend[-2,-1] vividlight
#-blend overlay
As long as I do not include the blending steps, all seems to work fine. However, as soon as I apply one of the blending (and therefore the -local command gets used internally) the code crashes if it gets executed in a thread different from the main one.
In other words, the crashes I see are not directly connected with parallel processing, but to - local commands being executed in a spawned thread.
As soon as I manage I’ll look into the gmic code for the local command, but maybe this piece of info will also ring some bells? 
Hi!
I’ve managed to somehow build a minimalistic failing command.
I get a crash as soon as I have four nested -local commands:
"-verbose + -l[0] -l[0] -l[0] -l[0] -endl -endl -endl -endl"
This is still working fine:
"-verbose + -l[0] -l[0] -l[0] -endl -endl -endl"
The crash occurs just at the beginning of the inner gmic::_run() function call.
Could it be a simple problem of stack size?
Ha yes, that could be a problem with the stack size.
I had such problems on Windows, and did a lot of work already to reduce the stack usage, but maybe this was not enough for MacOSX ?.
It’s a bit strange, because the stack size is known to be particularly small by default on Windows. On MacOSX, I have no ideas. Is it possible to allow a bigger stack size ?
From Apple’s documentation:
Apparently one can change the stack size via a linker flag:
-Wl,-stack_size,1000000
should set the stack size to 16MB.
However, if I set this flag my program gets killed with an obscure
Killed: 9
message and nothing else… therefore I could no check my hypothesis yet.
I have tried with various values of the stack size, always with the same result.
I have to admit that this is driving me a bit crazy! 
This has made me crazy for a couple a years now.
After all this time, I’m not crazy anymore, just a bit bored 
I think this time I got it fixed!
The trick was to force the stack size of newly created threads to some large value (I’ve set it to 8MB but that’s probably too much), using pthread_attr_setstacksize().
I could finally run the freaky details filter under OSX with four threads and see the CPU usage going well above 300%! However, I had no time yet for more extensive and systematic tests…
I have created a pull request on GitHub with the modified code that runs on my system.
@KaRo: could you check if things become stable on your system as well? You can either wait until David updates the official repository, or clone my fork: GitHub - aferrero2707/gmic-minimal: G'MIC is a full-featured open-source framework for image processing, providing several different user interfaces to convert/manipulate/filter/visualize generic image datasets, ranging from 1d scalar signals to 3d+t sequences of multi-spectral volumetric images, including 2d color images.
Sounds really promising. I’ll try but not in the next few days, I am fully occupied. Let me just wait for Davids updates.
Awesome news!
Actually, yes, reading this from : Technical Q&A QA1419: Customizing Process Stack Size
Q: My application maintains a large number of concurrent threads and needs to use a large amount of stack allocated data. How can I protect against overflowing my allocated stack space?
A: My application maintains a large number of concurrent threads and needs to use a large amount of stack allocated data. How can I protect against overflowing my allocated stack space?
Each Mac OS X process is launched with a default stack size of 8 Megabytes. This allocation is used exclusively for the main thread’s stack needs. Each subsequent thread created is allocated its own default stack, the size of which differs depending on the threading API used. For example, the Mac OS X implementation of Pthreads defines a default stack size of 512 Kilobytes, while Carbon MPTasks are created with a 4 Kilobyte stack.
Then I see that 512Kb is indeed too small.
Holy crap! That was just this ? What a waste of time! I had the same issue on Windows, but at least, the error message was "Stack overflow" which was clear enough to understand what was going on…
I’ve actually already worked hard these last years to decrease the stack usage in the G’MIC code (to fix the issue on Windows). The fact that the stack size for the main thread and the secondary threads are not the same didn’t help finding the issue. That’s really awesome to know, thanks a lot Andrea!
So, now, it would be great to determine the “optimal” stack size for each thread. I think 8Mb is maybe too much. On Windows, I’ve used a #pragma to set it to approx. 6.5Mb (line 147, file gmic.h). Maybe you could try with 6.5Mb too. Trying this ultimate recursive test to determine the best size could help: While the following code crashes, you need to add some stack size.
gmic _l=0 -m "foo : _l={\$_l+1} -foo" -parallel \"-skip\",-foo
which gives this (on Linux, so with a correct stack size and no crash) :
[gmic]-0./ Start G’MIC interpreter.
[gmic]-0./ Set global variable _l=‘0’.
[gmic]-0./ Import custom commands from expression ‘foo : _l={$_l+1} -foo’ (added 1 command, total 6197).
[gmic]-0./ Execute 2 commands ‘-skip,-foo’ in parallel and wait thread termination immediately.
[gmic]-0./*thread1/foo/ Set global variable _l=‘1’.
[gmic]-0./*thread1/foo/foo/ Set global variable _l=‘2’.
[gmic]-0./*thread1/foo/foo/foo/ Set global variable _l=‘3’.
[gmic]-0./*thread1/foo/foo/foo/foo/ Set global variable _l=‘4’.
[gmic]-0./*thread1/foo/foo/foo/foo/foo/ Set global variable _l=‘5’.
[gmic]-0./*thread1/foo/foo/foo/foo/foo/foo/ Set global variable _l=‘6’.
[gmic]-0./*thread1/foo/foo/foo/foo/foo/foo/foo/ Set global variable _l=‘7’.
…
[gmic]-0./*thread1/foo/foo/(…)/foo/foo/foo/foo/ Set global variable _l=‘61’.
[gmic]-0./*thread1/foo/foo/(…)/foo/foo/foo/foo/ Set global variable _l=‘62’.
[gmic]./*thread1/foo/foo/(…)/foo/foo/foo/foo/ *** Error *** Call stack overflow (infinite recursion ?).
Please, tell us. I’m so excited by the news. I think this could deserve a new stable release (currently planed is 1.6.6.0).
Having in the same week the GEGL stuff included in the plug-in for GIMP 2.9, and the bug fix for MacOSX… wow! 
According to :
http://man7.org/linux/man-pages/man3/pthread_create.3.html
On Linux/x86-32, the default stack size for a new thread is 2
megabytes. Under the NPTL threading implementation, if the
RLIMIT_STACK soft resource limit at the time the program started has
any value other than "unlimited", then it determines the default
stack size of new threads. Using pthread_attr_setstacksize(3), the
stack size attribute can be explicitly set in the attr argument used
to create a thread, in order to obtain a stack size other than the
default.
so it may be a good start to try 2 Mb for the default stack size no ?
Just my parallel enabled git version:
~ gmic _l=0 -m "foo : _l={\$_l+1} -foo" -parallel \"-skip\",-foo
[gmic]-0./ Start G'MIC interpreter.
[gmic]-0./ Set global variable _l='0'.
[gmic]-0./ Import custom commands from expression 'foo : _l={_l+1} -foo’ (added 1 command, total 4473).
[gmic]-0./ Execute 2 commands ‘-skip,-foo’ in parallel and wait thread termination immediately.
[gmic]-0./*thread1/foo/ Set global variable _l=‘1’.
[gmic]-0./*thread1/foo/foo/ Set global variable _l=‘2’.
[gmic]-0./*thread1/foo/foo/foo/ Set global variable _l=‘3’.
[gmic]-0./*thread1/foo/foo/foo/foo/ Set global variable _l=‘4’.
[gmic]-0./*thread1/foo/foo/foo/foo/foo/ Set global variable _l=‘5’.
[gmic]-0./*thread1/foo/foo/foo/foo/foo/foo/ Set global variable _l=‘6’.
[gmic]-0./*thread1/foo/foo/foo/foo/foo/foo/foo/ Set global variable _l=‘7’.
[gmic]-0./*thread1/foo/foo/(…)/foo/foo/foo/foo/ Set global variable _l=‘8’.
[gmic]-0./*thread1/foo/foo/(…)/foo/foo/foo/foo/ Set global variable _l=‘9’.
[gmic]-0./*thread1/foo/foo/(…)/foo/foo/foo/foo/ Set global variable _l=‘10’.Illegal instruction: 4
Hi! Is this my patched version or the one with the default stack size of 512KB?
Its the default one, no time as i said!
Carmelo Dr Raw noreply@discuss.pixls.us schrieb am Fr., 11. Sep. 2015
09:27: