Object proxy management not happy with bindings
Since the recent code to properly free proxy objects, we have some exit warnings and even crashes on some binding languages:
- The Python binding has no problem with libgimp cleaning code.
- The javascript goat exercise ends now with the following warnings:
gimp_plug_in_destroy_proxies: ERROR: GimpImage proxy with ID 1 was refed by plug-in, it MUST NOT do that!
gimp_plug_in_destroy_proxies: ERROR: GimpLayer proxy with ID 2 was refed by plug-in, it MUST NOT do that!
(goat-exercise-gjs:9429): Gjs-ERROR **: 16:14:29.689: Finalizing proxy for an already freed object of type: Gimp.Image
The first warnings are from GIMP which complains that the binding refed the image object. Then our code goes for unreffing it (it should not!), and the JavaScript interpreter now complains that the object has been unrefed on our side!
- The Lua binding is even worse as it just crashes:
gimp_plug_in_destroy_proxies: ERROR: GimpImage proxy with ID 1 was refed by plug-in, it MUST NOT do that!
gimp_plug_in_destroy_proxies: ERROR: GimpLayer proxy with ID 2 was refed by plug-in, it MUST NOT do that!
/home/jehan/.local/share/crossroad/roads/native/gimp-master/lib/gimp/2.99/plug-ins/goat-exercise-lua/goat-exercise-lua.lua: fatal error: Segmentation fault
Stack trace show it happens on lua_close()
, and further gc_call_finalizer.isra()
, which is where I guess the interpreter is trying to unref the stuff it refed (as it should).
Thread 1 (Thread 0x7f6012081b80 (LWP 9554)):
#0 0x00007f6012170fe4 in read () at /lib64/libc.so.6
#1 0x00007f600f28d011 in gimp_stack_trace_print (prog_name=prog_name@entry=0x41d4fe78 "/home/jehan/.local/share/crossroad/roads/native/gimp-master/lib/gimp/2.99/plug-ins/goat-exercise-lua/goat-exercise-lua.lua", stream=0x7f6012244780 <_IO_2_1_stdout_>, trace=trace@entry=0x0) at /home/jehan/dev/src/gimp-master/libgimpbase/../libgimpbase/gimputils.c:1342
status = 0
stack_printed = 0
gtrace = 0x0
gimp_pid = "9554", '\000' <repeats 11 times>
buffer = "X\203'\017`\177\000\000\340V*\017`\177\000\000pNI\351\377\177\000\000x\376\324A\000\000\000\000\320d)\017`\177\000\000\340\217\324A\000\000\000\000\240\017A\022`\177\000\000D\265B\022`\177\000\000\005", '\000' <repeats 15 times>, "x\203\324A\000\000\000\000\030\201'\017`\177\000\000PNI\351\377\177\000\000\236\"C\022`\177\000\000S\000\000\000\000\000\000\000\210\"\255\373", '\000' <repeats 12 times>, "\200G$\022`\177\000\000x\376\324A\000\000\000\000B\237\236\326EV\000\000\340X$\022`\177\000\000\236\"C\022`\177\000\000\000\000\000\000\000\000\000\000A\270\v\022`\177\000\000\000\000\000\000\000\000\000\000"...
read_n = <optimized out>
sync_fd = {13, 16}
out_fd = {17, 18}
fork_pid = 9570
pid = 9554
eintr_count = 0
tid = 9554
#2 0x00007f600f28d470 in gimp_stack_trace_query (prog_name=0x41d4fe78 "/home/jehan/.local/share/crossroad/roads/native/gimp-master/lib/gimp/2.99/plug-ins/goat-exercise-lua/goat-exercise-lua.lua") at /home/jehan/dev/src/gimp-master/libgimpbase/../libgimpbase/gimputils.c:1512
buf = "s\n\000\000\000\000\000\000\v\000\000\000\000\000\000"
#3 0x00007f600f2db65f in gimp_plugin_sigfatal_handler (sig_num=<optimized out>) at /home/jehan/dev/src/gimp-master/libgimp/../libgimp/gimp.c:1075
sigset = {__val = {0 <repeats 16 times>}}
#4 0x00007f60120bb600 in <signal handler called> () at /lib64/libc.so.6
#5 0x00007f6012410ed1 in () at /usr/lib64/lua/5.1/lgi/corelgilua51.so
#6 0x00007f6012410fb8 in () at /usr/lib64/lua/5.1/lgi/corelgilua51.so
#7 0x00005645d44f4347 in lj_BC_FUNCC ()
#8 0x00005645d44a6a48 in gc_call_finalizer.isra ()
#9 0x00005645d44c6416 in gc_finalize ()
#10 0x00005645d44c6560 in cpfinalize ()
#11 0x00005645d44f46b6 in lj_vm_cpcall ()
#12 0x00005645d44e96ce in lua_close ()
#13 0x00005645d449a66e in main ()
[Inferior 1 (process 9554) detached]
My conclusion is that I don't think we should presume on how the reference count should look like when the plug-in ends, because we have no control over the whole stack (when we deal with bindings). And we can't really say that a binding should not ref objects it creates. As long as it properly unref its references at the end, it is proper to let it do its own business.
Of course we lose a bit of nice warnings for C plug-ins, but I don't think these warnings are worth the pain.
@mitch, I don't just revert your changes because I wanted to write down here what was the problem with details. :-)
Also maybe you have other ideas to keep the whole cleaning system while not breaking bindings, but as said, not sure this is really worth wasting time. Let's just tell plug-in devs "these objects belong to libgimp" and if people don't follow rules, they have bugs to fix, that's it. :P