Bug 28955
| Summary: | various screensavers dumps core | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Need Real Name <mal> | ||||
| Component: | xscreensaver | Assignee: | Ray Strode [halfline] <rstrode> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 7.0 | CC: | jwz | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i386 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2004-11-09 15:54:28 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Can you try the xscreensaver from the wolverine beta? There was a bug in shadebobs fixed in 3.26. Without the debugging symbols, the traces aren't useful. I don't see *any* of these here. *** Bug 28956 has been marked as a duplicate of this bug. *** *** Bug 29138 has been marked as a duplicate of this bug. *** *** Bug 40572 has been marked as a duplicate of this bug. *** >Without the debugging symbols, the traces aren't useful.
> I don't see *any* of these here.
It is hard for me to get more debugging info,
I just found a 'core' file in my home directory.
Also, because so many xscreensaver programs dump core
may be it make sense not to strip debugging symbols
when building an rpm
That's just the thing. They *don't* dump core on any machine I've seen. >That's just the thing.
>They *don't* dump core on any machine I've seen.
All these core file were collected from 5 different RedHat 7.0 workstations
(with all updates applied)
with different hardware (i586, i686), memory (from 32Mb to 512Mb)
and disks.
At least one core file was found on every of these 5 computers.
Odd, we've never seen anything like this in testing here. Do these machines have *anything* in common? (processor type/speed, graphics card, etc.) You can try http://people.redhat.com/notting/xscreensaver/ ; there are binary RPMs built there with debugging symbols... No, everything is different in these machines. The only thing in common that some of them may stay for a a day or two with screensaver running and monitor power turned off. I will put this RPM with screensaver on three of these computers. This one just crashed
gdb /usr/X11R6/lib/xscreensaver/xrayswarm core
GNU gdb 5.0
Copyright 2000 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"...
Core was generated by `/usr/X11R6/lib/xscreensaver/xrayswarm'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/X11R6/lib/libXmu.so.6...done.
Loaded symbols for /usr/X11R6/lib/libXmu.so.6
Reading symbols from /usr/X11R6/lib/libSM.so.6...done.
Loaded symbols for /usr/X11R6/lib/libSM.so.6
Reading symbols from /usr/X11R6/lib/libICE.so.6...done.
Loaded symbols for /usr/X11R6/lib/libICE.so.6
Reading symbols from /usr/X11R6/lib/libXt.so.6...done.
Loaded symbols for /usr/X11R6/lib/libXt.so.6
Reading symbols from /usr/X11R6/lib/libX11.so.6...done.
Loaded symbols for /usr/X11R6/lib/libX11.so.6
Reading symbols from /usr/X11R6/lib/libXext.so.6...done.
Loaded symbols for /usr/X11R6/lib/libXext.so.6
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0 0xe332dd89 in ?? ()
(gdb) bt
#0 0xe332dd89 in ?? ()
#1 0x804c223 in screenhack_handle_events (dpy=0xbffff630) at screenhack.c:239
#2 0x804ba84 in screenhack (d=0x4, w=3221222960) at xrayswarm.c:1056
#3 0x804cc4e in main (argc=1, argv=0xbffffa84) at screenhack.c:584
#4 0x401bcf31 in __libc_start_main (main=0x804c490 <main>, argc=1,
ubp_av=0xbffffa84, init=0x8048f68 <_init>, fini=0x804e30c <_fini>,
rtld_fini=0x4000e274 <_dl_fini>, stack_end=0xbffffa7c)
at ../sysdeps/generic/libc-start.c:129
(gdb)
Are the machines, even though they have different hardware, running at the same bpp or screen resolution? The resolution is the same 1024x768 bpp and frequencies are different. I seems being able to get one crash with xrayswarm (the others dod not crash yet) when using a package compiled with debugging symbols. It seems crashes in 0x804c223 in screenhack_handle_events (dpy=0xbffff630) at screenhack.c:239 (see above) I will wait for few weeks, may be I will be able to collect more core files. I don't know what could be causing such a widespread set of crashes, but
screenhack_handle_events just does this:
while (XPending (dpy))
{
XEvent event;
XNextEvent (dpy, &event);
screenhack_handle_event (dpy, &event);
}
so unless "dpy" is corrupted memory, I don't see how that could be crashing.
Chances are there's an upstream memory corruption, and this is just where it
finally manifests.
If you have reproducible crashes: does adding --sync alter the behavior?
Created attachment 90676 [details]
gdb backtrace of screen saver core dump on Redhat 8.0 system
I am seeing core dumps from various screen savers on Redhat 8.0. The attachment
is a gdb bt of one of the core files.
I've also seen this on RH8, and as far as I can tell, it's a bug in whatever version of Mesa GL they're shipping with whatever version of XFree86 they're shipping (I don't remember the numbers, but as of last week, I was running the latest version for which RPMs are available anywhere.) This GL stuff is doubtless unrelated to the earlier stuff in this bug report about screenhack_handle_events. Please report this to whoever is responsible for OpenGL in RH8? Adding the X maintainer for the r128 DRI crash. Removing X maintainer, r128 bug filed separately as bug 86368. may be a duplicate of Bug #73827 Hi, This bug report is very old and the problem reported is probably fixed by now. I'm going to close this report, but if you encounter the problem in FC3 or with a recent version of xscreensaver, please feel free to reopen. |
The shadebobs dumbs core. The trace is attached (the symbols are stripped in the binary, so the trace is not very useful). core file is available upon request Vesion: rpm -q xscreensaver xscreensaver-3.25-4 gdb /usr/X11R6/lib/xscreensaver/shadebobs core ..... Loaded symbols for /lib/libm.so.6 ---Type <return> to continue, or q <return> to quit--- Reading symbols from /lib/libc.so.6... done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x804a1e5 in strcpy () at ../sysdeps/generic/strcpy.c:31 31 ../sysdeps/generic/strcpy.c: No such file or directory. (gdb) (gdb) bt #0 0x804a1e5 in strcpy () at ../sysdeps/generic/strcpy.c:31 #1 0xc1c9 in ?? () #2 0x804a5da in strcpy () at ../sysdeps/generic/strcpy.c:31 #3 0x804b5de in strcpy () at ../sysdeps/generic/strcpy.c:31 #4 0x401b9b5c in __libc_start_main (main=0x804ae30 <strcpy+6392>, argc=2, ubp_av=0xbffffac4, init=0x8049098 <_init>, fini=0x804f91c <_fini>, rtld_fini=0x4000d634 <_dl_fini>, stack_end=0xbffffabc) at ../sysdeps/generic/libc-start.c:129 (gdb)