On Sat, 2009-04-04 at 12:41 -0500, Callum Lerwick wrote: > You are honestly expecting Aunt Tillie to log in to a console and grovel > through log files? No, Aunt Tillie is going to hit c-a-d or the power button like she does in windows. She doesn't know the difference between that and c-a-backspace anyway, and the only visible difference for her is that full reboot takes slightly longer. > Here, how about a real life test case: > > <snip> Running this in rawhide doesn't do anything particularly special. The app crashes, certainly, but input continues to work afterward. Haven't tried with F10 yet, maybe it's worse there. > Now how about Seg, the guy who debugs Little Billy's game. Take out the > 'SDL_FULLSCREEN' flag from sdlcrash, recompile and run it under gdb. > Wait for the crash... kablooey! I run in to this situation all the > goddamn time trying to debug Second Life. It grabs the mouse when you > click to move the camera, which is what you're doing most of the time. > If it crashes then you're screwed. I assume that you mean "gdb it from within X" here, in which case yes, this is difficult. Option one is to set a breakpoint on the signal handler and do: (gdb) commands 1 Type commands for when breakpoint 1 is hit, one per line. End with a line saying just "end". > call XUngrabPointer(SDL_Display, 0) > call XUngrabKeyboard(SDL_Display, 0) > end Except of course that SDL_Display isn't really a variable, so, figure that bit out. Or just do it from the signal handler in SDL or the app itself, except then you have to set the breakpoint after those calls have run. You're playing with fire a bit here since if you faulted in the middle of an xlib call, the ungrab requests are probably going to be sent as garbage. Other option is to somehow get an XKillClient() to happen, which would break the server's connection to the now-halted client, and thus reset grab state. Again, if you do this from within the crashing client you run the risk of corrupting xlib's state, so it's only better than the ungrab hack if you can get it to fire from some other client. Third option from within the crashing app itself is close(ConnectionNumber(dpy)), I suppose. That'll trigger disconnect handling in the server without generating more protocol. > Is there some way to recover other than killing off the process, which > screws any chance of debugging it because it's no longer running? Remote > debugging isn't always particularly convenient. Yep, life is hard. You may be able to use the GL support in Xephyr instead? That would limit the scope of the grab to the nested Xephyr server. - ajax
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
