Summary: | DrKonqi left multiple copies of KWin running after creating bugreports | ||
---|---|---|---|
Product: | [Applications] drkonqi | Reporter: | Dennis Schridde <heri+kde> |
Component: | general | Assignee: | Unassigned bugs mailing-list <unassigned-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | kwin-bugs-null, mail |
Priority: | NOR | ||
Version: | 5.3.1 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
See Also: |
https://bugs.kde.org/show_bug.cgi?id=349921 https://bugs.kde.org/show_bug.cgi?id=353428 |
||
Latest Commit: | http://commits.kde.org/kwin/69aa80750f8d61a5db6311c33751461041a260d5 | Version Fixed In: | 5.6 |
Sentry Crash Report: | |||
Attachments: | Screenshot |
Description
Dennis Schridde
2015-06-07 13:39:12 UTC
Created attachment 93054 [details]
Screenshot
Either the old instances didn't receive the XCB_SELECTION_CLEAR event (KSelectionOwner) or KSelectionOwner invalidly claims success for the new instance or the old instances perform a crash-on-exit, being stopped rather than terminated. Can you gdb into one of the zombies and "bt" to check where it's hanging around? I just also found a ton of stale drkonqi instances… I submitted several bugreports against crashed KWin instances using DrKonqi, so something did not work in cleaning those up… It's normal that DrKonqi keeps the process alive until it has at least gathered the backtrace (because otherwise it cannot) - the problem seems in DrKonqi (or involve it) Did you see and close the DrKonqi windows? If not, are there any DrKonqi windows (xwininfo -root -tree) If yes, can you map them ("xdotool windowmap 0x123456" - 0x123456 ideally being the actual WId as printed by xwininfo ;-) (In reply to Thomas Lübking from comment #4) > It's normal that DrKonqi keeps the process alive until it has at least > gathered the backtrace (because otherwise it cannot) - the problem seems in > DrKonqi (or involve it) Yes, but the bugreport was already sent in all cases, or "the application" was "restarted" (without any effect) and the dialogue closed. > Did you see and close the DrKonqi windows? Yes, that's where all the bugreports came from. The windows were closed after creating the bugreport. As there seemed to be a lot of repetitive backtraces, which DrKonqi did not detect as duplicates of existing reports, I just clicked "restart" for several crashes, too. > If not, are there any DrKonqi windows (xwininfo -root -tree) There were no DrKonqi windows left after creating the bugreports (I checked after restarting KWin manually). When I detected the stale processes, I killed them, so I cannot check using the command you suggested right now, but I will as soon as there are stale processes again. Some more info: On the console that I started KWin on, I get the following output when it crashes: areKeySymXsDepressed: any of 2 0 : keySymX=0x "ffe9" i= 8 mask=0x "1" keymap[i]=0x "1" Cant find EGLConfig, returning null config Unable to find an X11 visual which matches EGL config 0 Could not initialize OpenGL Application::crashHandler() called with signal 6; recent crashes: 1 KCrash: Application 'kwin_x11' crashing... KCrash: Attempting to start /usr/lib64/libexec/drkonqi from kdeinit sock_file=/run/user/1000/kdeinit5__0 kwin: unable to claim manager selection, another wm running? (try using --replace) [1]+ Stopped DISPLAY=:0 kwin_x11 --replace dschridde@ernie ~ $ dschridde@ernie ~ $ exit There are stopped jobs. dschridde@ernie ~ $ fg DISPLAY=:0 kwin_x11 --replace ^C^C^C^C^C^C^C^C^A2Killed Now apparently the process transitions to the Stopped state (without any DrKonqi window), and when resuming it (using "fg"), it will not react anymore at all, until it receives SIGKILL. The process stops on crash to allow dr konqui to attach to it - that's normal. DrKonqi not showing up is of course a problem - if it cannot be started, the process should of course be continued (into death) About "not react at all" - yes, it's stopped ;-) Does it (though I hope you don't suffer too much from this) "react" (and die) if you "kill -SIGCONT" it? (In reply to Thomas Lübking from comment #7) > Does it (though I hope you don't suffer too much from this) "react" (and > die) if you "kill -SIGCONT" it? Now that the original bug is fixed, it is more difficult to test this. But I'll try next time I run into similar trouble. What you say is sensible, of course, so I assume the reason it does not react to ^C is that it is stopped. Git commit 69aa80750f8d61a5db6311c33751461041a260d5 by Thomas Lübking. Committed on 14/01/2016 at 22:40. Pushed by luebking into branch 'master'. force restart on crash We don't want to actively release claims on segfaults, but then drkonqi can stop us while we're still holding the WM privs. => If KWin performs a crash-restart, it forcefully takes WM privs (since the old instance shall be replaced for quite sure) Related: bug 353030, bug 353428 REVIEW: 126741 FIXED-IN: 5.6 M +3 -2 main_x11.cpp http://commits.kde.org/kwin/69aa80750f8d61a5db6311c33751461041a260d5 |