Re: XScreensaver locks up whole system.
On Tue, Aug 03, 1999 at 11:06:18AM +1000, Dan Everton wrote: > On Tue, Aug 03, 1999 at 10:22:49AM +1000, Dan Everton wrote: > > On Mon, Aug 02, 1999 at 01:21:03PM -0500, Stephen Pitts wrote: > > > Kinda offtopic suggestion, but rebuild your kernel with > > > the "magic SysReq" key option, then Alt-SysRq-K will > > > > Well, unfortunately, magic sysrq is already compiled in and did nothing. > > Tried everything from Alt-SysRq-K to Alt-SysRq-l. Nothing. Wow..it really crashed hard. > Well, after following the debugging procedure outlined above I've got > nothing. Basically, the program refuses to crash unless it's being displayed > by the xserver (xserver-svga 3.3.3.1-10). It can run just fine for ages > while the X server is not on screen, but as soon as I switch back to the > xserver, the whole systems locks (if I happen to catch the penetrate program > in it's end of level display). > > Any other hints? > Try running gdb over a telnet connection. If you want to get really into it, printout the source for penetrate and start setting breakpoints. Narrow down what is actually happening and where (in the code) it locks the system. Then, trace that back up the chain of command into the xserver (possibly rebuild X with -g..damn that would take a long time!). Because the Linux kernel is not known for causing system lockups, I would use Norton Diagnostics or something to run a full memory check. Personally, I can't reproduce your bug. I'm using kernel 2.2.7 and the custom-compiled X server provided by nVidia. Penetrate runs quite nicely, though I prefer xmatrix :-) -- Stephen Pitts [EMAIL PROTECTED] webmaster - http://www.mschess.org
Re: XScreensaver locks up whole system.
On Tue, Aug 03, 1999 at 10:22:49AM +1000, Dan Everton wrote: > On Mon, Aug 02, 1999 at 01:21:03PM -0500, Stephen Pitts wrote: > > Kinda offtopic suggestion, but rebuild your kernel with > > the "magic SysReq" key option, then Alt-SysRq-K will > > Well, unfortunately, magic sysrq is already compiled in and did nothing. > Tried everything from Alt-SysRq-K to Alt-SysRq-l. Nothing. > > > kill all prorams on the current VC. Running xscreensaver > > in the gdb debugger will let you find out where > > it crashed and what might have caused the crash. > > It's not actually xscreensaver that causes the crash. It's one of the > programs that comes with it called "penetrate". It's a screensaver that > simulates a game of Missile Command (oh nostalgia). > > > Try this: > > 1. Use "apt-get source xscreensaver" to download > > the xscreensaver source. You'll also need the > > lesstif dev package. > > 2. Rebuilt xscreensaver with debugging info > > Adding 'export CFLAGS=-g' right above the first > > ./configure line in debian/rules should work. > > should work. > > 3. Startx and switch to another virtual console. > > Log in as the user that started the x server, > > and type "export DISPLAY=:1". Then start > > xscreensaver with "gdb xscreensaver". > > 4. Type "run args", where args are the command > > line arguments to xscreensaver. Wait until > > it crashes, then use the SysRq combo to > > kill the xserver. Go back to the gdb console > > and type 'where'. That will tell you where it > > crashed. > > -- > > Stephen Pitts > > [EMAIL PROTECTED] > > webmaster - http://www.mschess.org > > I'll try the above debugging stuff. But I don't know if I'll get useful > information out because the last few times I've tried to run the program, it > has locked the system so hard it doesn't respond to pings. > > Dan Well, after following the debugging procedure outlined above I've got nothing. Basically, the program refuses to crash unless it's being displayed by the xserver (xserver-svga 3.3.3.1-10). It can run just fine for ages while the X server is not on screen, but as soon as I switch back to the xserver, the whole systems locks (if I happen to catch the penetrate program in it's end of level display). Any other hints? Dan -- Dan Everton <[EMAIL PROTECTED]> | "Have you tried thinking like a shower?" www.psynet.net/fada | KBHR's Chris in the Morning
Re: XScreensaver locks up whole system.
On Mon, Aug 02, 1999 at 01:21:03PM -0500, Stephen Pitts wrote: > Kinda offtopic suggestion, but rebuild your kernel with > the "magic SysReq" key option, then Alt-SysRq-K will Well, unfortunately, magic sysrq is already compiled in and did nothing. Tried everything from Alt-SysRq-K to Alt-SysRq-l. Nothing. > kill all prorams on the current VC. Running xscreensaver > in the gdb debugger will let you find out where > it crashed and what might have caused the crash. It's not actually xscreensaver that causes the crash. It's one of the programs that comes with it called "penetrate". It's a screensaver that simulates a game of Missile Command (oh nostalgia). > Try this: > 1. Use "apt-get source xscreensaver" to download > the xscreensaver source. You'll also need the > lesstif dev package. > 2. Rebuilt xscreensaver with debugging info > Adding 'export CFLAGS=-g' right above the first > ./configure line in debian/rules should work. > should work. > 3. Startx and switch to another virtual console. > Log in as the user that started the x server, > and type "export DISPLAY=:1". Then start > xscreensaver with "gdb xscreensaver". > 4. Type "run args", where args are the command > line arguments to xscreensaver. Wait until > it crashes, then use the SysRq combo to > kill the xserver. Go back to the gdb console > and type 'where'. That will tell you where it > crashed. > -- > Stephen Pitts > [EMAIL PROTECTED] > webmaster - http://www.mschess.org I'll try the above debugging stuff. But I don't know if I'll get useful information out because the last few times I've tried to run the program, it has locked the system so hard it doesn't respond to pings. Dan -- Dan Everton <[EMAIL PROTECTED]> | "Have you tried thinking like a shower?" www.psynet.net/fada | KBHR's Chris in the Morning
Re: XScreensaver locks up whole system.
Kinda offtopic suggestion, but rebuild your kernel with the "magic SysReq" key option, then Alt-SysRq-K will kill all prorams on the current VC. Running xscreensaver in the gdb debugger will let you find out where it crashed and what might have caused the crash. Try this: 1. Use "apt-get source xscreensaver" to download the xscreensaver source. You'll also need the lesstif dev package. 2. Rebuilt xscreensaver with debugging info Adding 'export CFLAGS=-g' right above the first ./configure line in debian/rules should work. should work. 3. Startx and switch to another virtual console. Log in as the user that started the x server, and type "export DISPLAY=:1". Then start xscreensaver with "gdb xscreensaver". 4. Type "run args", where args are the command line arguments to xscreensaver. Wait until it crashes, then use the SysRq combo to kill the xserver. Go back to the gdb console and type 'where'. That will tell you where it crashed. -- Stephen Pitts [EMAIL PROTECTED] webmaster - http://www.mschess.org
