Most of the time DT 321 seg faults when I want to paste certain settings (CTRL-SHIFT-V) to many raw files.
To Reproduce
Expected behavior
Normal pasted settings - happens but in 40% of time approx.
Platform (please complete the following information):
Heres's a backtrace it left in my tmp folder
darktable_bt_OB9LP0.txt
Additional context
Happens with or without OpenCL enabled - it doesn't matter.
Happens on both arch packaged and flatpak versions respectively.
I have noticed, but might be totally wrong, that having Lut 3D module enabled during or after shift-pasting makes the crashing considerably more often.
However, one time it crashed when I just had "sharpened" module ticked to paste. However, if I shift-pasted "sharpened" module with no Lut3d enabled both on the source and destination image, there was no crash.
I have just followed the above steps. I did this test twice. The first time it worked fine having unselected several random modules The second time it crashed. The second time I only unselected raw b&w point. I selected different sets of images to paste to in each case. I did not enable Lut 3D. I did this on a fresh install.
A quick look at the backtrace points out to threading issues. What happens if you use only 1 CPU thread (in preferences -> CPU/GPU) ?
A quick look at the backtrace points out to threading issues. What happens if you use only 1 CPU thread (in preferences -> CPU/GPU) ?
Setting background threads to 1 produces the same results.
Here's the backtrace it just generated:
darktable_bt_OFECP0.txt
Indeed, and the BT doesn't say what program triggered this faulty thread sync. Perhaps if you start gdb darktable then run ?
If you can compile dt yourself it would be nice to have the backtrace with debug information. Here we just know that the crash occurs in copy_history libs, but no line indicated...
Indeed, and the BT doesn't say what program triggered this faulty thread sync. Perhaps if you start
gdb darktablethenrun?
I'm not familiar with gdb. I did what you said and after DT crashed I got this in the terminal:
Thread 1 "darktable" received signal SIGSEGV, Segmentation fault.
0x00007ffff773e420 in g_list_copy_deep () from /usr/lib/libglib-2.0.so.0
Should I run some other commands or generate a more comprehensive debug list?
If you can compile dt yourself it would be nice to have the backtrace with debug information. Here we just know that the crash occurs in copy_history libs, but no line indicated...
I could try later in the evening. You cannot reproduce this issue? The guy that replied here also reproduced this issue in the 2nd try.
No I can't reproduce and I have pasted the settings of an history using Lut3D to more than 20 pictures. One by one, or after selecting all of them.
Can you add more info to the description to reproduce ? What settings in Lut3D ? Is that a cube file ? Any precision could help reproduce.
No I can't reproduce and I have pasted the settings of an history using Lut3D to more than 20 pictures. One by one, or after selecting all of them.
Can you add more info to the description to reproduce ? What settings in Lut3D ? Is that a cube file ? Any precision could help reproduce.
I'm away on the phone so can't offer more insight now, sorry. But @franklepore reproduced it with unselecting raw b&w values, as he said in his post. Make sure the images you are pasting onto do not have any prior history and are like freshly imported. Mine are canon raw files. As he said he didn't need lut3d to reproduce it.
I've reproduced with easy steps:
The last step crash the first or second time.
It looks like a memory corruption on the act_on->images GList *
#0 0x00007ffff77b4ef7 in g_list_copy_deep ()
at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#1 0x00007fff8c6d5868 in paste_parts_button_clicked
(widget=<optimized out>, user_data=<optimized out>)
at /home/obry/dev/builds/darktable/build/src/src/libs/copy_history.c:279
#2 0x00007ffff6ae3206 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#3 0x00007ffff6b018d4 in g_signal_emit_valist ()
at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#4 0x00007ffff6b01edf in g_signal_emit ()
at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
I've not yet spotted the code where this is wrong though !
Should be fixed !
I installed darktable-git from AUR package for Arch and seems fixed!
Well done, that was fast!
Most helpful comment
Should be fixed !