I've been editing a large shoot at high speed (150-200 images per hour), and have experienced multiple crashes when advancing to the next image. The most common segfault location has been
#2 0x00007f6a7f5209e0 in <signal handler called> () at /lib64/libc.so.6
#3 0x00007f6a7f62fb2a in __memmove_avx_unaligned_erms () at /lib64/libc.so.6
#4 0x00007f6a834e4c34 in _event_image_draw (cr=0x354fb00, user_data=<optimized out>, widget=<optimized out>) at /home/ralf/src/darktable/src/dtgtk/thumbnail.c:656
While the memcpy() at that location in thumbnail.c is wrapped in a mutex to prevent the buffer it is copying from changing during the copy, the buffer dimensions it uses were previously read outside the critical section and thus might not be valid any more (easily the case if you've changed the crop aspect ratio).
Since width, height, and buffer address are tightly linked, they need to be read and especially updated atomically. So the point(s) where the buffer changes also need to include updates to width and height in the same critical section. I haven't had a chance to look for those locations to check whether that's the case.
Steps to reproduce
Will try to generate a reproducer after I deliver this shoot....
Expected behavior
No response
Logfile | Screenshot | Screencast
No response
Commit
No response
Where did you obtain darktable from?
self compiled
darktable version
4.7.0+1206~g9920ae7c1c (current master as of earlier today)
What OS are you using?
Linux
What is the version of your OS?
Mageia 9
Describe your system?
32C64T AMD ThreadRipper 3970X, 64 GB RAM, X11.
Are you using OpenCL GPU in darktable?
None
If yes, what is the GPU card and driver?
No response
Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip
Describe the bug
I've been editing a large shoot at high speed (150-200 images per hour), and have experienced multiple crashes when advancing to the next image. The most common segfault location has been
While the memcpy() at that location in thumbnail.c is wrapped in a mutex to prevent the buffer it is copying from changing during the copy, the buffer dimensions it uses were previously read outside the critical section and thus might not be valid any more (easily the case if you've changed the crop aspect ratio).
Since width, height, and buffer address are tightly linked, they need to be read and especially updated atomically. So the point(s) where the buffer changes also need to include updates to width and height in the same critical section. I haven't had a chance to look for those locations to check whether that's the case.
Steps to reproduce
Will try to generate a reproducer after I deliver this shoot....
Expected behavior
No response
Logfile | Screenshot | Screencast
No response
Commit
No response
Where did you obtain darktable from?
self compiled
darktable version
4.7.0+1206~g9920ae7c1c (current master as of earlier today)
What OS are you using?
Linux
What is the version of your OS?
Mageia 9
Describe your system?
32C64T AMD ThreadRipper 3970X, 64 GB RAM, X11.
Are you using OpenCL GPU in darktable?
None
If yes, what is the GPU card and driver?
No response
Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip
No response