By always dividing, it’s about 10 attempts.
Oh ok.
And my questions about the file itself?
Are you able to provide any insight?
But you won’t delete one line at a time. With a smart approach to removing certain fragments it will take orders of magnitude less attempts. Configuration key names are structured, so it’s easy to delete them by domain. For example, delete everything related to plugins/lighttable or plugins/darkroom and see if that helps. If deleting a block helped, the next step is to return it and delete a certain part of it to narrow the search.
It is a storage for configuration data, key-value pairs. Much like .ini files in Windows or .plist in macOS.
You don’t lose anything, but the developers will lose the ability to find the code that is responsible for the crash.
1 Like
You won’t help to fix the problem for others.
darktablerc basically contains the UI settings (layout, mask opacity) and processing settings (most of which can be adjusted from the UI, some only manually).
@kofa, thanks for the info. Veryhelpful!
So far, I’ve narrowed it down to the first 100 lines of code.
I’ll keep plugging away…
At least now, I feel like I’m having small wins. 
1 Like
Looks like it is between lines 12-25.
allow_lab_output=false
ask_before_copy=TRUE
ask_before_delete=TRUE
ask_before_discard=TRUE
ask_before_move=TRUE
ask_before_remove=TRUE
ask_before_rmdir=FALSE
autosave_interval=10
backthumbs_inactivity=5.000000
backthumbs_initialize=FALSE
backthumbs_mipsize=1080p
bauhaus/scale=1.400000
bauhaus/zoom_step=TRUE
brush_smoothing=medium
darktable is still crashing out after 15 seconds.
@Bruce_Williams My guess is that this is a background thumbnail generator.
Yep, it’s in those 3 lines starting with ‘backthumbs’.
That’s what causes the crash.
Try changing backthumbs_mipsize=1080p to backthumbs_mipsize=never
1 Like
It’s unlikely that it’s any of the ask_before... settings. allow_lab_output also seems like something for export? However, there is the background processing (backthumbs_mipsize...). Try setting backthumbs_mipsize=never.
BTW, you can find the descriptions here: darktable/data/darktableconfig.xml.in at master · darktable-org/darktable · GitHub
The pair of you nailed it!
Changing that value to ‘never’ has fixed the issue.
Thank you so much for helping me on this, everyone who contributed.
Right now, it’s past my bedtime, so I’m gonna scoot for now, but so happy to have got to the bottom of this.
Many thanks!
1 Like
Good night! You’ll have to open a bug report to get it really fixed.
1 Like
I suspect that this resolved issue is behind all of this: Darktable Issue 17127. Will try @Bruce_Williams’ solution when st my pc
@Bruce_Williams glad to hear you’re back up and running!
1 Like
Succes! Changing that line in darktablerc now to backthumbs_mipsize=never fixed it. And for those who are curious: value before was 5K. To me looks like something in the logic which does thumbnail updates. Thanks to @Bruce_Williams for doing the leg work on this one (in addition to your channel) and kofa for bringing us back to basics/fundamentals (if in doubt start from a known good, non-customised starting point)!
1 Like
Thank you for the kind words, @pinkadoe.
And I’m glad my pain helped you find a way back to a working darktable as well!
Revisiting this thread as I upgraded to DT4.8.1 today and found it has the same issue, i.e. crashes all by itself if backthumbs_mipsize has another value than never. That was surprising; the feedback on fedora’s bugzilla suggested the cause had been found and fixed in 4.8.1. @bruce_williams do you see the same?
What system are you on? Mac? Could you provide a log with -d pipe -d opencl ?
Morning/Morgen,
I am running DT on Fedora 40 Linux; CPU-only, 16 Gb RAM. Attached is a log as requested of starting DT (from CLI). DT segfaults shortly after starting (light table loads succesfully on last collection):
dtlog.txt (95.3 KB)
The only other observations I can offer now (after having edited a large project):
- No difference whether using large or standard for darktable resource utilisation (CPU/Mem)
- DT starts and is usable when backthumb_mipsize set to never. It crashes with other values (tried 1080, 5K)
- But even with backthumb_mipsize set to never DT 4.8.0 and 4.8.1 crash much more frequently during normal use than 4.6.x or before (I think I started using 1.4 so have a feel for what is normal on my hardware). Crash only happens when in lighttable mode. This can be either when doing something challenging (click-zoom in on 2-3 side-by-side images), but also when zooming in on a single image or in some cases scrolling through a large collection
I am eager to get his fixed and willing to help, but will need to balance with day-to-day life and the (sad?) reality that last time I did proper coding & debugging was ~40 years ago on a VAX/VMS. I am pretty at ease on CLI, just no experience with debugging under linux (other than my own shell scripts)…
Hmm. Also on F40, never seen that. YOu are sure you generated the log with -d pipe -d opencl ? Please add -d cache and report again. No understanding yet what might be wrong.