https://bugs.kde.org/show_bug.cgi?id=525304
Krzysztof Łastowski <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|NEEDSINFO |CONFIRMED Resolution|BACKTRACE |--- --- Comment #2 from Krzysztof Łastowski <[email protected]> --- Sorry for the noise on this one — I think I conflated two separate things when filing it, and want to close out the crash part properly. Context on how this was filed: my actual problem was NixOS rebuilds failing because fontinst replaces my symlinked fontconfig file with a plain copy. While digging into that, I found an exit(255) sitting next to it in the logs and assumed it was the cause, so I filed both together here. Since then I've tried to get a live backtrace for the crash (debug symbols installed, gdb attached with catch throw/breakpoints on exit/abort, triggered via the real Fonts KCM several times, once even clicking through Font Management and switching font groups before closing the window). Every single time, the process either ran fine or hit its own deliberate 30s-idle exit(0) shutdown (KFI::FontInst::connectionsTimeout(), confirmed against the 6.6.6 source) — never the reported exit(255). So this crash is real but rare/non-deterministic, at least for me, and not worth spending more of your time chasing without a reliable repro. I don't have anything more to give you on it right now — happy to reopen with a real backtrace if it recurs and I catch it, but for now consider the crash part low-priority/stalled on my end. The part I'm actually still curious about is separate and not a crash at all: is it expected that fontinst rewrites files under ~/.config/fontconfig/conf.d/ unconditionally on every start, even when nothing changed? I had a look at the 6.6.6 source — the conf.d writes I found go through fontconfig's own atomic-replace API (FcAtomicCreate/FcAtomicReplaceOrig), which is the standard safe-write mechanism, so this isn't sloppy code. But atomic replace-via-rename unavoidably destroys whatever was at that path before, including a symlink — which is exactly what happens to files placed there by declarative dotfile managers (home-manager, chezmoi, GNU Stow, etc., a fairly common setup on Linux). Folder::init()'s addDir() call looked like it should be conditional (if (!hasDir), i.e. only writes if something's actually missing), but empirically the file gets touched on every single start regardless of whether anything changed. Is that intentional (e.g. some other normalization pass I didn't find), or would a "skip if unchanged" check be a reasonable ask? Not blocking for me either way — I've already worked around it on my end — just curious whether it's worth a separate report. -- You are receiving this mail because: You are watching all bug changes.
