… crash handler outlives it

Three symptoms in the Windows reports behind #1476 -- no thumbnail cache on disk, preferences not saved, "it closes on a crash" -- are one event, and the ordering inside dt_cleanup() is what couples them.

Neither thing was persisted until the very end. dt_conf_set_*() writes only the in-memory table; the settings file is written by dt_conf_save(), whose sole caller on the normal path was dt_conf_cleanup(), at the tail of dt_cleanup(). And a thumbnail reaches the disk cache only when its cache entry is released, which for everything still resident happened inside dt_mipmap_cache_cleanup(), a hundred lines earlier but still well past the risky part. So a session's preferences AND its whole thumbnail cache both depended on reaching the end of a long serial teardown, behind a window hidden at the start of it -- a teardown that includes dt_ctl_switch_mode_to(""), i.e. the darkroom leave() path this tree has documented hazards in.

Both are now banked immediately after the last point that can ask the user anything, before any of that runs. The later calls stay: they catch what the teardown itself writes (window geometry, panel sizes, sentry's session counters) and any thumbnail another thread still held.

dt_mipmap_cache_flush_to_disk() is the new entry point, and it is the existing eviction walk at a fill ratio of 0 rather than a second loop: the walk already skips entries it cannot trywrlock, honours _lock_demoting, and runs the cleanup callback that does the writing. The walk never locked, because both its callers inside cache.c already hold cache->lock, and it had no caller outside the file. It is now _cache_gc_locked(), private, and the public dt_cache_gc() takes cache->lock around it and returns the cost reclaimed: a public function that touches the LRU unlocked was a trap for the first outside caller, and the _locked suffix means "the caller holds the lock" elsewhere in the tree (conf.c's _dt_conf_get_var_locked()).

dt_sentry_shutdown() moves from the FIRST statement of dt_cleanup() to just before dt_conf_cleanup(). sentry_close() uninstalls the crash handler, so running it first left the entire teardown unreported: an exit crash produced no event at all, which is why #1476 had no crash data to work from. It has to stay ahead of dt_conf_cleanup(), because it writes the clean-session counter and the session duration through dt_conf_set_*() and that save is what puts them on disk.

Two supporting changes the above made necessary:

- The save now takes cf->mutex. It never did, which was survivable only while its one normal caller ran with every other thread joined: the table is read key by key there and written under the mutex by every dt_conf_set_*(), so an unlocked walk concurrent with a write reads a GHashTable mid-rehash. The pre-existing call in opencl.c had the same exposure.
- dt_conf_flush() saves the singleton, and is the only public way to save. Every other public getter and setter here already takes no dt_conf_t *. opencl.c, the last caller that named darktable.conf to save, calls it too, which closes conf's last cross-module reference (doc/globals-migration.md); the save itself is private to conf.c.

And the preferences dialog now saves when it closes, which is the direct answer to "my settings are not saved": until this commit, a preference set at the start of a session lived only in memory for the whole of it.

Measured: build clean, 0 warnings. A CLI run with an isolated --configdir/--cachedir reports the flush once, in the new position, and writes a 5570-byte anselrc. Injecting abort() into the teardown immediately after the two new calls still leaves anselrc on disk, where on master the only dt_conf_save() on that path runs after the injection point and leaves none.

The thumbnail half, measured in the GUI with a shim that pages through the lighttable and then quits (Xephyr 1920x1080, default 1000 MB budget): 400 thumbnails, 124 MB, flushed in 259 ms; 400 at 494 MB in 817 ms, all written by the flush and none left for the end; 60 NEF quit while rendering, 8 of 12 written by the flush and the 4 still rendering written by dt_mipmap_cache_cleanup(). No thread waited on the cache lock during a flush. doc/shutdown.md has the table; doc/sentry.md places dt_sentry_shutdown() at its new position.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…a failed save is reported

The save opened anselrc with "wb", which empties it before the first line is written: a process that died during a save left a 0-byte file and lost every setting. Measured under gdb with ansel-cli, killed inside the save after the open: anselrc went from 12825 bytes to 0. This branch saves more often, and once right before the part of the teardown that can fail, so the window matters more than it did.

The table is now serialised into a buffer under cf->mutex and written with g_file_set_contents(), which writes a temporary file and renames it over the old one. Killed at the rename, the same run leaves anselrc intact at 12825 bytes, plus an orphan anselrc.XXXXXX. The write stays under the mutex so that two saves land in the order they read the table; with the fsync GLib does before the rename, the mutex is held 4-7 ms per save on ext4 (10 runs), against 0.2-0.7 ms before.

A failed write was silent. It is printed on stderr with its reason, and dt_conf_flush() returns 1. The preferences dialog, the one caller with a user in front of it who has just changed settings, raises a "Settings not saved" alert with the configuration folder as its item. Checked under gdb by pointing the write at a missing directory: the stderr line, a return of 1, and a normal exit.

tests/unittests/test_conf_save.c pins the replacement: a handle opened on the old file before a flush must still read the old content after it. Run against the save put back to fopen("wb"), that test fails and the two others in the file (what is written, what a failure returns) pass, as they should.

doc/preferences.md describes when the settings reach the disk, the atomic replacement, its cost, and how a failure is reported.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>