DT v5.6.1/5.7 - appimage, launches but closes immediately after.

Software darktable
1

Strange issue. Whenever I launch either version of appimage, the app launches, seems to think about it a while (30+sec) and then closes.

If I’m opening the app by clicking on the icon, lighttable launches all the images load but one, which says working (I can’t click another photo or category in this state) and then closes the app altogether.

I can select a photo from the file manager, right click over it and choose the Darktable app to open that image. Sometimes this works, but more often than not, the app likewise launches into darkroom mode and then closes.

I rename the config folder, restart DT and all is well again, except I have to reload my watermark, styles etc… This is a repeatable process.

What’s going on? What do I need to do to help fault find?

I’m using Debian13 KDE.

Hope someone can help!

Baldrick.

2

I am not the best person to give technical advice here so I defer to others who may answer. However, I recently had a similar problem with DT. The resolution for me was to remove the last image I had worked on from the folder that was being opened when DT loaded. I presume there was something wrong in the xmp file for the edit I had done (just guessing), but once this picture was removed DT opened fine for me. Your description suggests a single image may also be the cause of your problem.

1 Like
3

Thanks Terry,

So I’ve had uncle Claude into it, and it seems like a candidate for a github bug report - but looking at what’s required there is waaaaay past my pay grade!

As per Claude:
Now we have the real answer — and it’s a completely different function from before:

Thread 42 "worker 5" received signal SIGSEGV, Segmentation fault.
#0 process (...) at .../src/iop/highlights.c:887

This crashes inside darktable’s own highlights (highlight reconstruction) module — not the pipeline recursion depth, not corrupted history order. This is happening at pipeline position 5, which is very early/shallow — nothing to do with the duplicate-entry bloat we were chasing before. Let me check if this is a known bug in this darktable version.

This looks very relevant — GitHub issue #21996 describes almost the exact same symptom pattern on 5.6/5.7 AppImages. Let me pull up the full issue to see if it names the same crash location or has a fix/workaround.

That one’s a different crash (GTK side panel), not a match. Let me search more specifically for the highlights.c module crash.

That release-notes fragment is very promising — it explicitly mentions: “Fixed a bug in CPU opposed highlights code that could lead to out of memory crashes.” That’s the “opposed” highlight reconstruction method, in the CPU code path — exactly matching our crash (process() in highlights.c, and it crashed identically whether OpenCL was on or off, meaning it was hitting the CPU path either way). Let me confirm which release this fix landed in, since you’re on 5.6.1.

The page I fetched only went up to 5.4.1, but the search snippet that mentioned the highlights fix came from further up (a newer release). Let me get the 5.6.1 release notes specifically.

This is the answer, but with a twist: I checked the official 5.6.1 release notes, and they explicitly say:

“Fixed a bug in CPU opposed highlights code that could lead to out of memory crashes.”

That’s describing exactly this — the highlights.c module, CPU path, crash/OOM — and it’s supposed to already be fixed in the version you’re running (5.6.1). So either this is a related-but-distinct bug the 5.6.1 fix didn’t fully cover, or your specific images are hitting an edge case in that same code path that survived the patch. Either way, this is now a genuinely new finding worth reporting — but let’s get you unblocked first.

Since the highlights module runs as part of darktable’s default pipeline (even on fresh imports, hence why it crashed on 6 brand-new images with zero history), and it’s stored per-image in each .xmp’s history with specific reconstruction parameters, the fastest way to unblock your whole library is to temporarily disable that module in every sidecar, bypassing the crashing code entirely. You can always re-enable it per-image later once this is sorted upstream, or after switching to a different reconstruction method.

Claude created a highlights disabling script for the .xmp files which I ran, then: rm ~/.config/darktable/library.db and reloaded the library again. This time everything loaded as required.

I’m hoping one of the devs might see this and give them enough info to provide a fix, since there seems to be a bit of a history with the highlights going back a few versions.

I know some are really perturbed by the use of Ai, but in this case it worked as a diagnostic tool and hopefully will help result in a fix.

Many thanks!

4

It’s a known bug, you’ve probably imported an xmp someone created with a newer version of darktable after an upgrade to the highlights reconstruction module (possibly that someone was yourself :-D).

Usually incompatible module versions should be caught and handled but in this case it leads to dt crashing.

See this github issue: DT crashes when opening a sidecar · Issue #22189 · darktable-org/darktable · GitHub

Fix for your setup for the time being: delete the offending images RAW+xmp, then dt won’t try to load the history stack of it.

And for the time being be extra careful with mixing stable and nightly.

2 Likes
5

That was probably the case for me as I was running both 5.6 and 5.7 at the time. I have deleted 5.7 for the moment and will play with 5.7 in a couple of weeks when I don’t need to revert to 5.6 for any editing.

1 Like
6

Yup, this is where I think I’ve been going wrong. I thought there would be two different instances between versions, a neither the twain shall meet scenario. Maybe they are, but it also makes sense that they share the same xmp files too!

Thanks for helping me understand @mino

So Claude disabled the highlight module in all the existing xmp side-car files. Is there a process to enable them again?

How do I find the offending RAW-xmp file?

Finally, is there any benefit to sandboxing 5.7, so there’s less chance of cross-contamination between versions?

1 Like
7

Yes, sounds like a plan I need to follow as well! Thanks @Terry.

8

Maybe grep through the XMPs searching for highlights module with modversion 4 - see this post Calda House, Loch Assynt - #28 by gwbarn.

The issue is though that the contaminated data is now also inside your library.db. You could try to delete library.db and then import images step by step and see when dt crashes. Or sql into your db and fix it there, too. But at least to fiddeling inside databases always feels a bit scary :wink: .

There is a much more convenient alternative though: The fix to prevent crashing has been backported to the 5.6.x branch on github (but is not included in the officiall appimage; I am hoping for a 5.6.2). Just compile the AppImage from that branch and the crashing should be fixed. If you have problems with that ping me and I will compile it for you later.

Yes: Preventing scenarios just like the one you are experiencing :wink: . See our guide on how to run parallell installations.

3 Likes
9

If I had run DT 5.7 with its own configuration file would that have helped? I presume it wouldn’t help. I presume the issue is the DB and xmp files so deleting the last edited image before the crash resolved the issue for me.

10

See the linked guide. If you use a different config but work on the same files you end up affecting their xmps as well if you don’t disable the appropriate setting in the preferences.

For maximum safety I recommend using a different config AND keeping the raw files separate.

3 Likes
11

Oh, grep for modversion=“5” because it got updated in master; that’s why I included the modversion 4 line

You would need to use a different library with the --library parameter and probably disable XMPs as well (you can temporarily use that option with another command line parameter)

1 Like
12

In the end I sandboxed 5.7 and duplicated a few images to play with. Not ideal, but it seems to work fine now. I really like what 5.8 is promising.

Funnily enough, it’s the ablity to use condensed module controls, which is a real winner for when using laptops! Though I also like being able to now change the button accent colour, the new contrast & texture module and the saturation curve!

Thanks to all for your hard work and effort.

1 Like
13

@mino, I replied to you in another thread, but I’m wondering if this is the issue I have now encountered on my Windows installation. Although I’m careful to keep my dev and production installations separate, I think I accidentally launched the buggy master briefly without specifying a different config folder, and I’m worried that it has corrupted my main production installation as it looks to be a problem with the Highlights Reconstruction module.

So I’d appreciate knowing the lowest risk method to troubleshooting this problem. Worth noting that my production installation has a lot of photos in it, so it’s not a simple matter of a few folders here and there. I just want to revert to the way it was a couple of days ago when this wasn’t an issue.

14
  1. Backup your entire config folder (I do that daily with a script). Maybe also make sure your photos+xmps have a current backup.
  2. Rename library.db to something like library.db.old
  3. Pick one of the automated snapshots of library.db (inside the config folder) from an appropriate point in time and copy+rename it to library.db.
  4. Start darktable. If dt asks you what to do about differences between library and xmp choose to overwrite the xmp.
15

Thanks!
So, I’ve found “library.db-pre-5.7.0” and “data.db-pre-5.7.0” in my config folder, so I guess those are the ones I want?

The only things I did today in my production environment was remove a bunch of colour labels, so I guess all that work would be lost, but that’s not a big deal.

My photos and XMPs are always backed up because the sync with the cloud.

16

Those should be the backups generated just when you launched 5.7. Though better take a look of their timestamps for a sanity check.

And there should be a number of library.db with “snapshot” in their filename: library.db-snp-(timestamp). These are generate by darktable on every launch (I think), the number of snapshots to be kept can be set in the preferences.

And: Does your cloud sync provide versioning - if not it isn’t a backup ;-).

17

Thanks.
I restored those main backups, and everything seems to be working fine now.

For future reference, do those snapshots serve a similar purpose but are generated each time darktable starts rather than just at a new installation? So, in theory, if you find one from just before the problem started, that would be better to use than the installation one because it’s more recent?

I do have versioning with my cloud sync, although not sure for how many days. It’s just for the XMPs and images, not for the DB.

1 Like
18

In theory, yes.

Just a word of caution: I’d not trust my precious photos with just a bit of versioning. Concerning the config: I have set up a shell script to run at startup which backs up the entire config directory into a zip, which keeps 14 days worth of config backups. Gives me peace of mind :wink: .

19

Yes, agreed. Over the last month or so, I’ve been researching alternative solutions, and I’m considering getting a NAS or similar. I knew I would have to face this sooner or later, and my library will only get bigger.