https://bugs.kde.org/show_bug.cgi?id=525060
Adrian Damian <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |--- Ever confirmed|0 |1 --- Comment #9 from Adrian Damian <[email protected]> --- > it seems like whatever state gets corrupted during the crash is tied to the > location of the Kate binary OK, I think I figured out why this is happening, and a possible fix. The state is tied to the binary path because SingleApplication (used as fallback on MacOS instead of DBus) uses it to generate the blockServerName passed to QSharedMemory[1]. I think the resources are these (the name remains the same across Kate runs): $ lsof -nP -p $(pgrep -f '[k]ate') | grep PSX kate 11480 lemon 3r PSXSEM 0t0 uBXItzN77tkVzYDz4KgS_Q== kate 11480 lemon 4u PSXSHM 16384 uBXItzN77tkVzYDz4KgS_Q== After the first run, the socket /var/folders/f9/0pdlwcdj6bv2xqtb5gnmdt140000gn/T/uBXItzN77tkVzYDz4KgS_Q== appears on disk, if I delete it after the crash, it doesn't appear when I start Kate again. (I tried running all Kate instances with QT_LOGGING_RULES="*=true", but I'm not seeing anything related to that name, nor SingleApplication.) [1]: https://invent.kde.org/utilities/kate/-/blob/e8f5ff6a4a60489b118658c37bb82aef5b8444ca/3rdparty/SingleApplication/singleapplication_p.cpp#L169 --- The possible fix is to update SingleApplication from upstream, it got a "Fix QSharedMemory on macOS with Qt 6.6+" change a few months ago: https://github.com/itay-grudev/SingleApplication/commit/ccc013ee1b58ce41508e9aeac5afc0a1d112c29e When I get some time I'll try to do it myself, but I'm somewhat out of my depth. -- You are receiving this mail because: You are watching all bug changes.
