I have a debug log. I’ll send it to your e-mail, its quite long!
(lldb) thread info -s
thread #2: tid = 0x564e6d, 0x0000000102f98840 libclang_rt.asan_osx_dynamic.dylib`__asan::AsanDie(), stop reason = Use of deallocated memory
{
“access_size” : 4,
“access_type” : 0,
“address” : 107064944795528,
“description” : “heap-use-after-free”,
“instrumentation_class” : “AddressSanitizer”,
“pc” : 4301440776,
“stop_type” : “fatal_error”
}
That was really helpful, thanks. I copy/paste the answer I’ve written to you, so that others can see what we do 
OK I think I’ve a somehow clear idea about the issue…
Let me explain this to you:
and the second is dedicated to the measurement of the timing.
The second threads does nothing more than a loop ‘do… wait a little bit… while (time<timeout)’. When testing for the timeout, it calls the math parser, just for testing the ‘time<timeout’ condition. The math parser is always associated to an image (usually the last image on the list), so when it initializes itself, it looks for the image dimensions and store them somewhere.
For this reason, it is not safe to change that the first thread T1 changes the number of images in the list while executing. Because thread T2 will regularly try to access the image information as well.
What happens probably here is that T1 is removing the image in the list with command ‘rm’, while T2 is actually trying to get its dimensions (but the image does not exist anymore in the list!). That leads to a wrong memory access in the math parser, just as your log tells it.
Now, I’m not sure about a working solution. I guess one possible solution would be to encapsulate thread T2 in a empty local environment, so that it never tries to read image informations.
After all, T2 does not have to access any kind of image information, as it’s only job is to test the timeout, nothing more.
This suggests that the following trick should be done : Replace line 18315 of gmic_stdlib.gmic :
"do if $|-"$|">$2 __is_timeout"$id"=1 error \"\" elif $__done"$id" break fi wait 100 while 1"
by
"l[] do if $|-"$|">$2 __is_timeout"$id"=1 error \"\" elif $__done"$id" break fi wait 100 while 1 endl"
This isolates thread T2, and prevents him to access image information.
Could you try this, and tell me if that fixes your issue ?
Thanks again for all your tests !
I have changed it in update290.gmic
Several gmic trials did not show any error anymore!
Try now with gimp…
Unluckily no change in immediate timeouts and especially not in pink … bianca!
Seemingly reflected my cli test not the gimp plugin problem!
Still I don’t understand the different behavior of the same plugin in the two different gimp builds!
Possibly still another tricky error?
Probably a tricky error yes!
Just tried to compile the PINK binaries, using the provided CMakeLists. No luck:
In file included from /home/dtschump/Downloads/Pinktmp/include/pink.h:323,
from /home/dtschump/Downloads/Pinktmp/src/lib/liar_fseries.cxx:54:
/home/dtschump/Downloads/Pinktmp/include/uiSqhool.hpp: At global scope:
/home/dtschump/Downloads/Pinktmp/include/uiSqhool.hpp:193:8: error: redeclaration of ‘void pink::uiSqhool::insert_image(const image_type&, const string&, std::string)’ may not have default arguments [-fpermissive]
193 | void uiSqhool::insert_image ( const image_type & image,
| ^~~~~~~~
Any idea?
EDIT: Just removed the default argument, and it seems to resume… Fingers crossed 
EDIT2: Nope, this doesn’t succeed:
[ 13%] Building CXX object lib/CMakeFiles/pink.dir/__/liar/powerwatsegm.cpp.o
[ 13%] Building CXX object lib/CMakeFiles/pink.dir/__/liar/random_walker.cpp.o
[ 14%] Linking CXX shared library libpink.so
/usr/bin/ld: CMakeFiles/pink.dir/mcskel3d.c.o: in function `lskel3d5':
mcskel3d.c:(.text+0x8df0): multiple definition of `lskel3d5'; CMakeFiles/pink.dir/mcskel2d3d.c.o:mcskel2d3d.c:(.text+0x5e10): first defined here
/usr/bin/ld: CMakeFiles/pink.dir/mcskel3d.c.o: in function `lskel3d6':
mcskel3d.c:(.text+0x8f80): multiple definition of `lskel3d6'; CMakeFiles/pink.dir/mcskel2d3d.c.o:mcskel2d3d.c:(.text+0x6090): first defined here
collect2: error: ld returned 1 exit status
make[2]: *** [lib/CMakeFiles/pink.dir/build.make:3529: lib/libpink.so] Error 1
make[1]: *** [CMakeFiles/Makefile2:91: lib/CMakeFiles/pink.dir/all] Error 2
make: *** [Makefile:152: all] Error 2
With cmake I had also difficulties. For a quick result I used makelin!
I’ll look to find a modified CMakeLists,txt
Perhaps the attached one, please try, I am not sure
CMakeLists.txt (26.6 KB)
(Never had this error!)
Don’t switch Python frontend on, only Bash …
I’d like to switch off timeout completely. Is it possible to extend the gui? Actually I cannot set 0 or negative time
Just an additional Info:
This function fx_karo_pink_bianca works not only in the Gimp 2.10.14 build but also in the gmic_qt.app!
I don’t understand. Negative time ? In which case it could be used?
Command apply_timeout already allows no timeout by passing 0 as the timeout argument.
EDIT : Or maybe you are speaking about the timeout settings in the plug-in ?
David, in the GUI of the plugin timeout zero is not possible!
Ok, I’ve sent a mail to the plug-in developer, he will have a look at this.
He has pushed a modification to allow 0 as the timeout value.
Not tested yet, but I think it should be OK.
Otherwise, I’d really like to know more about your timeout issue.
With the recent changes, I’m no longer sure what works and what doesn’t work anymore for you.
The actual situation (build of cli, gimp plugin and standalone app) from today (develop branch) shows the following:
cli works with the gui functions using pink
gmic_qt works with the gui functions using pink
gimp plugin called from Gimp 2.10.14 (from gimp.org) works like cli
gimp plugin called from Gimp 2.10.18 (local MacPort build) works like cli except for Pink…Bianca
Bianca delivers timeout even if it is called without timeout!
[gmic_gimp_qt]./preview/ v 3 fx_karo_pink_bianca_preview 5,60,5,1,0,1,0,50,50
[gmic]-1./ Start G’MIC interpreter.
[gmic]-1./fx_karo_pink_bianca_preview/gui_split_preview/ Import custom commands from expression ‘_split_preview : -fx_karo_pink_bianca 5,60,5,1,0,1,0,50,50 k[0]’ (1 new, total: 4222).
[gmic]-1./fx_karo_pink_bianca_preview/gui_split_preview/ Set local variable ‘is_movable=1’.
[gmic]-1./fx_karo_pink_bianca_preview/gui_split_preview/ Set multiple variables ‘posx=50’, ‘posy=50’.
[gmic]-1./fx_karo_pink_bianca_preview/gui_split_preview/ Set multiple variables ‘pw=410’, ‘ph=605’.
[gmic]-1./fx_karo_pink_bianca_preview/gui_split_preview/*repeat/*local/ Set local variable ‘is_timeout=0’.
[gmic]-1./fx_karo_pink_bianca_preview/gui_split_preview/*repeat/*local/*local/ Apply command ‘_split_preview’ on image [0], with no timeout.
[gmic]-1./fx_karo_pink_bianca_preview/gui_split_preview/*repeat/*local/*local/ Set local variable ‘is_timeout=1’.
[gmic]-2./fx_karo_pink_bianca_preview/gui_split_preview/*repeat/*local/*if/ Keep image [1] (1 image left).
[gmic]-1./fx_karo_pink_bianca_preview/gui_split_preview/ Discard definition of custom command ‘_split_preview’ (1 found, 4221 commands left).
[gmic]-1./ End G’MIC interpreter.
Even with timeout 0 the earlier mentioned timeouts from Reptorian and Joan Rake still appear!
Still there are some messages by quitting Gimp:
(GIMP:31914): Gtk-WARNING **: 18:02:52.334: mnemonic “a” wasn’t removed for widget (0x7fa8e5e5deb0)
(GIMP:31914): Gtk-WARNING **: 18:02:52.334: mnemonic “b” wasn’t removed for widget (0x7fa8e9269c70)
(GIMP:31914): Gtk-WARNING **: 18:02:52.334: mnemonic “d” wasn’t removed for widget (0x7fa8e6808080)
(GIMP:31914): Gtk-WARNING **: 18:02:52.334: mnemonic “e” wasn’t removed for widget (0x7fa8e9282080)
(GIMP:31914): Gtk-WARNING **: 18:02:52.334: mnemonic “f” wasn’t removed for widget (0x7fa8e9290050)
(GIMP:31914): Gtk-WARNING **: 18:02:52.334: mnemonic “h” wasn’t removed for widget (0x7fa8e60c1ac0)
(GIMP:31914): Gtk-WARNING **: 18:02:52.334: mnemonic “n” wasn’t removed for widget (0x7fa8e5e52980)
(GIMP:31914): Gtk-WARNING **: 18:02:52.334: mnemonic “r” wasn’t removed for widget (0x7fa8e5e9be40)
(GIMP:31914): Gtk-WARNING **: 18:02:52.334: mnemonic “s” wasn’t removed for widget (0x7fa8e5e6a260)
(GIMP:31914): Gtk-WARNING **: 18:02:52.334: mnemonic “w” wasn’t removed for widget (0x7fa8e5e8a8d0)
/Applications/MacPorts/GIMP.app/Contents/Resources/GIMP: GEGL-WARNUNG: (…/gegl-0.4.22/gegl/buffer/gegl-tile-handler-cache.c:1076):gegl_tile_cache_destroy: runtime check failed: (g_queue_is_empty (&cache_queue))
EEEEeEeek! 4 GeglBuffers leaked
I think the gimp plugin in connection with the 2.10.18 gimp gets anywhere a signal for timeout although the processing was ok. The log shows there was an image what was not displayed since timeout was signaled. That was the reason I asked for the possibility to let it run without timeout, rsp. timeout zero!
I think that has to do with multi-threading. Is there a possibility to force one thread only?
Not if you are using apply_timeout (used by split_preview), because as I explained above, the very principle of this command is to launch two threads, one for the processing, the other for the timeout check.
Hmm, is it possible that there is an exchange between the two threads AND are there really only two or does the processing thread possibly divide? Or differently said, is the processing thread really limited to one thread?
Just a thought:
Command split_preview was not showing a difference between a command that actually timed-out, and a command that failed (because of an error encountered in that command).
I’ve fixed this, and pushed a filter update.
Maybe you could try. It is possible that what you took for a timeout is in fact an error in the command executed (maybe the PINK executable is not found?). With the new apply_timeout and split_preview the error will be now visible in the preview widget.
I’ll try, still the functions are working in different environments, only in that local MacPorts build this timeout appears, with exactly the same data and the same build (at least for the Gimps).
I am waiting for the Gimp.org MacOS build 2.10.18 to see what happens!
I think I have to wait for the 11 o’clock update?
No, I’ve already pushed it, so clicking the ‘update’ button should download the modified version.
Doesn’t this change anything?
in filter $HOME/.config/update290.gmic, you can check that line 41911 is
if 0$_is_timeout gui_timeout_preview