https://bugs.kde.org/show_bug.cgi?id=508085
nyanpasu64 <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #11 from nyanpasu64 <[email protected]> --- I ran into this bug on my own. Observations: - If I run set -Ux GTK_USE_PORTAL 1 in Fish, launching Firefox by clicking SyncThingy will not set the variable but fall back to GTK file dialogs. Launching Firefox from a pinned app will. This is strange because in both cases Firefox is spawned by systemd --user -> /usr/lib64/firefox/firefox. - You don't need to click Esc to trigger the bug; I've triggered crashes by repeatedly saving an image, then clicking Save or pressing Enter or Alt+S (<50% success rate each time). In the past when faced with this kind of mystery crash, I've had success adding logging to program control flow. I would record events which happened, check for program inconsistencies, and dump the sequence of events to a file (and alert the user) if an error was detected. My code is located at https://github.com/Dn-Programming-Core-Management/Dn-FamiTracker/blob/b4ea10d93bfbd9bac906f59d7e619d765e23463e/Source/SoundGen.cpp#L77-L180. The bug I was tracing was harder because it was multithreaded (is this one too?) and extremely rare to catch, while this KDE one is harder because (looking at the ASan log) it involves complex Qt control flow like d-pointers, the Qt event loop, and timers. The primary barrier here is that I don't know the desktop portal codebase or how to build and run a modified codebase locally; I think the people most equipped to track this down are existing KDE developers. - The design of "multiple file dialogs from one server process" suggests using actor concurrency/memory management to isolate this behavior? I don't know much about it. -- You are receiving this mail because: You are watching all bug changes.
