From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513 Description of problem: The circuit screensaver frequently dumps core on an SMP i686 box with standard full limbo install in the gnome environment. On my voodoo based system it dumps core after approximately 10 minutes. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Set Circuit to screensaver in gnome 2. allow screensaver to activate, or preview. 3. check for core files as they accumulate OR 1. run /usr/X11R6/lib/xscreensaver/circuit & 2. Wait approximately 10 minues for screensaver to core dump. Actual Results: The screensaver dies, and core files accumulate in users home directory, about 1 every 10 minutes. A total of 56 in the past 10 hours alone. Expected Results: circuit screensaver should have continued to display without dumping core every 10 minutes Additional info: Require password was not enabled The box is an SMP PIII 600 machine on a Supermicro system board All disks excluding CDROM are SCSI Video card is 3DFX Voodoo 5, as configured by Limbo installer Limbo packages installed were custom installation, full install (everything) No additional packages have been added to the Limbo beta excluding kernels for testing (this is one of my kernel dev boxes) Problem occurs withe the supplied Limbo kernel, as well as all 2.4.19-pre1 AC kernels (1-3) [root@nautilus jmforbes]# ls -al core* | grep 7-13 -rw------- 1 jmforbes dba 8466432 07-13 00:05 core.18790 ... -rw------- 1 jmforbes dba 8802304 07-13 04:48 core.20140 -rw------- 1 jmforbes dba 8425472 07-13 04:55 core.20172 core.20984: ELF 32-bit LSB core file of 'circuit' (signal 11), Intel 80386, version 1 (SYSV), from 'circuit' core.21016: ELF 32-bit LSB core file of 'circuit' (signal 11), Intel 80386, version 1 (SYSV), from 'circuit
Can you get a gdb backtrace? This works for me on a Neomagic chipset, so I wonder if it's a DRI or DRM issue.
nautilus:[~]> gdb /usr/X11R6/lib/xscreensaver/circuit GNU gdb Red Hat Linux (5.1.92-3) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (no debugging symbols found)... (gdb) run Starting program: /usr/X11R6/lib/xscreensaver/circuit (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...[New Thread 1024 (LWP 24608)] (no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... Program received signal SIGFPE, Arithmetic exception. [Switching to Thread 1024 (LWP 24608)] 0x40492dd7 in gl_test_os_katmai_exception_support () from /usr/X11R6/lib/modules/dri/tdfx_dri.so (gdb) next Single stepping until exit from function gl_test_os_katmai_exception_support, which has no line number information. 0x40492b01 in check_os_katmai_support () from /usr/X11R6/lib/modules/dri/tdfx_dri.so (gdb) next Single stepping until exit from function check_os_katmai_support, which has no line number information. 0x40492c11 in gl_init_all_x86_transform_asm () from /usr/X11R6/lib/modules/dri/tdfx_dri.so (gdb) next Single stepping until exit from function gl_init_all_x86_transform_asm, which has no line number information. Program received signal SIGSEGV, Segmentation fault. 0x080544b2 in ya_random () (gdb) backtrace #0 0x080544b2 in ya_random () #1 0xbffff280 in ?? () #2 0x0804ef0f in drawgrid () #3 0x0804f25e in display () #4 0x0804f9df in draw_circuit () #5 0x08052306 in xlockmore_screenhack () #6 0x0804a758 in screenhack () #7 0x080506bc in main () #8 0x420165c4 in __libc_start_main () from /lib/i686/libc.so.6
X bug in the DRI support module, apparently.
There are long-time-standing known issues with Voodoo 4/5 support which I am unable to resolve due to not having the hardware. The specs for this are also unavailable publically. Some of these issues could be resolved however if I had the hardware. Postponing until I can get a Voodoo 4/5 to play with.
This problem doesn't occur on other hardware which I've tested it on. Deferring until I obtain a Voodoo 4/5 card with which to reproduce and debug.
While not an optimal situation for debugging, I would be more than happy to give you an account and root access on this box here for testing. You cannot see the sceensaver, but could tell if it dumps core, usually happens within 10 minutes. I only use this box for kernel testing, and Limbo testing as of late. I will migrate my testing over to some of my other boxes while you work. Please email me direct if you are interested. iostream. I will throw a fresh install on the box and give you root access.
I've got a Voodoo 5 now.
Justin, It may or may not be relevant, but you should attach your xfree log file and config file, so Mike can compare what you have to what is happening, to what he gets with his voodoo5 if he can reproduce it.
I appreciate the sentiment Mike, but Mike Harris has my Voodoo 5 card, I sent it to him, that is how he got one. Justin
Yeppers.. Note, in case it sounds funny above claiming to have the Voodoo 5 now, I put that there for others reading the report as well. I've investigated this problem a couple times now, but got pulled away to other things since. I'm hoping to go over all the open 3Dfx bug reports soon, and hopefully resolve as many as possible. That's what the 82778 blocker is for. One of my todo lists tracking. ;o)