|Summary:||xrestop takes my xserver down|
|Product:||[Fedora] Fedora||Reporter:||Zdenek Kabelac <zkabelac>|
|Component:||xorg-x11-server||Assignee:||X/OpenGL Maintenance List <xgl-maint>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-07-09 15:01:54 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Zdenek Kabelac 2008-03-14 16:33:37 UTC
Description of problem: When I run xrestop and tpb is running - it destroyes Xserver (and my consoles are gone). When I kill tpb prior to run of xrestop - it stays alive. #0 0x0000003533632f75 in raise () from /lib64/libc.so.6 Missing separate debuginfos, use: debuginfo-install xorg-x11-server.x86_64 (gdb) bt #0 0x0000003533632f75 in raise () from /lib64/libc.so.6 #1 0x0000003533634ae3 in abort () from /lib64/libc.so.6 #2 0x0000003533673ea8 in __libc_message () from /lib64/libc.so.6 #3 0x0000003533679828 in malloc_printerr () from /lib64/libc.so.6 #4 0x000000353367be66 in free () from /lib64/libc.so.6 #5 0x00007fe5d1de6eb0 in ?? () from /usr/lib64/xorg/modules/extensions//libextmod.so #6 0x00000000004462d4 in Dispatch () #7 0x000000000042c7bd in main () I assume it's probably not really a fault of xrestop and as there are no debugsymbol packages for Fedora's Rawhide X server - feel free to reassign this bug to the right place Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Comment 1 Matěj Cepl 2008-03-18 10:04:02 UTC
(In reply to comment #0) > Missing separate debuginfos, use: debuginfo-install xorg-x11-server.x86_64 [... snip ...] > as there are no debugsymbol packages for Fedora's Rawhide X server what? why do you think you have that line in the output there?
Comment 2 Zdenek Kabelac 2008-03-18 20:33:47 UTC
Indeed you are correct - my fedora debug repositories were incorrectly set, but even when they were fixed debuginfo-install still din't worked - but yum install managed to install server debug info - I've also added glibc infos but for sure I don't have space for every debuginfo package - I also assume the modules are loaded in different places - thus here is a little bit better backtrace: #0 0x0000003533632f75 in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); Missing separate debuginfos, use: debuginfo-install audit.x86_64 dbus.x86_64 expat.x86_64 freetype.x86_64 gcc.x86_64 hal.x86_64 libXau.x86_64 libXdmcp.x86_64 libXfont.x86_64 libcap.x86_64 libdrm.x86_64 libfontenc.x86_64 libpciaccess.x86_64 libselinux.x86_64 mesa.x86_64 openssl.x86_64 pixman.x86_64 xorg-x11-drv-i810.x86_64 xorg-x11-drv-keyboard.x86_64 xorg-x11-drv-mouse.x86_64 zlib.x86_64 (gdb) bt #0 0x0000003533632f75 in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x0000003533634ae3 in abort () at abort.c:88 #2 0x0000003533673ea8 in __libc_message (do_abort=<value optimized out>, fmt=<value optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:170 #3 0x0000003533679828 in malloc_printerr (action=<value optimized out>, str=<value optimized out>, ptr=<value optimized out>) at malloc.c:5949 #4 0x000000353367be66 in __libc_free (mem=<value optimized out>) at malloc.c:3625 #5 0x00007fdeef777e80 in ?? () #6 0x00007ffff79b6756 in ?? () #7 0x00007ffff79b6755 in ?? () #8 0x00007ffff79b6757 in ?? () #9 0x00007ffff79b6754 in ?? () #10 0x00007ffff79b6752 in ?? () #11 0x00007ffff79b6751 in ?? () #12 0x00007ffff79b6753 in ?? () #13 0x0000000000c9efb0 in ?? () #14 0x000000460017fa01 in ?? () #15 0x0000000000000023 in ?? () #16 0x0000000000d64200 in ?? () #17 0x0000000000511f33 in XaceHookDispatch (client=0x23, major=13234236) at xace.c:52 #18 0x00000000004462d4 in Dispatch () at dispatch.c:454 #19 0x000000000042c7bd in main (argc=8, argv=0x7ffff79b6938, envp=<value optimized out>) at main.c:441 Looks to me like some double-free - but so far I'm unable tu run Xorg in gdb - it start to loop 100% on CPU - but debugger can't be attached - any idea how to attach gdb to Xorg ?
Comment 3 Matěj Cepl 2008-03-19 16:20:34 UTC
(In reply to comment #2) > Missing separate debuginfos, use: debuginfo-install audit.x86_64 dbus.x86_64 > expat.x86_64 freetype.x86_64 gcc.x86_64 hal.x86_64 libXau.x86_64 libXdmcp.x86_64 > libXfont.x86_64 libcap.x86_64 libdrm.x86_64 libfontenc.x86_64 > libpciaccess.x86_64 libselinux.x86_64 mesa.x86_64 openssl.x86_64 pixman.x86_64 > xorg-x11-drv-i810.x86_64 xorg-x11-drv-keyboard.x86_64 xorg-x11-drv-mouse.x86_64 > zlib.x86_64 THanks.
Comment 4 Zdenek Kabelac 2008-03-19 17:14:45 UTC
Well I think currently the bigger problem is - why the Xorg is not able to run inside gdb and busy loops somewhere - this seems to be the only way how to catch modules loaded on runtime (those 0x7f.... addresses) - have not had time to investigate more this issue.... When I'll have more info I'll post here.
Comment 5 Matěj Cepl 2008-03-20 06:24:18 UTC
X server was not designed to be run inside of gdb. Take a look at http://wiki.x.org/wiki/Development/Documentation/ServerDebugging for more informatino how to debug Xorg. Aside from the more complicated stuff described there, most of the interesting information (including backtraces) goes to /var/log/Xorg.0.log, so if you could attach yours here as uncompressed attachmnet, it would be great. Thanks.
Comment 6 Zdenek Kabelac 2008-03-20 11:10:43 UTC
After todays' Xorg update I'm not able to replicate my crash with xrestop easily anymore - I'll keep an eye on this - but it's possible it's now fixed.
Comment 7 Zdenek Kabelac 2008-03-20 12:42:30 UTC
Update - the bug is still there :( - I've hit the bug again - unfortunately I've not had attached gdb to Xorg at this moment :( - it's not not as deterministic as it used to be and it work ok most of the time... So once I'll be lucky enough to have next machine with attached gdb to my Xorg - I'll post a report
Comment 8 Matěj Cepl 2008-03-20 22:51:45 UTC
OK, let's give you a month, and unless you will be able to provide me with a good backtrace until then, I will close this bug as unreproducible. OK?
Comment 9 Matěj Cepl 2008-03-21 17:53:13 UTC
Chmm, so I can reproduce it, but only when gdb is not attached to the Xorg process :-(
Comment 10 Zdenek Kabelac 2008-03-21 23:09:18 UTC
Ok - month not really needed ;) I've slightly modified my test case to get a reliable error case. On the other hand - I guess this trace just shows the effect and not the reason of fault - imho the memory got damaged probably earlier. #0 0x0000003533632f75 in raise () from /lib64/libc.so.6 #1 0x0000003533634ae3 in abort () from /lib64/libc.so.6 #2 0x0000003533673ea8 in __libc_message () from /lib64/libc.so.6 #3 0x0000003533679828 in malloc_printerr () from /lib64/libc.so.6 #4 0x000000353367be66 in free () from /lib64/libc.so.6 #5 0x00007fd271f89e80 in ProcXResQueryClients (client=0xc97650) at xres.c:105 #6 0x00000000004462d4 in Dispatch () at dispatch.c:454 #7 0x000000000042c7bd in main (argc=8, argv=0x7fff7a5f16b8, envp=<value optimized out>) at main.c:441 As there were some rawhide updates - now I'm running: xorg-x11-server-Xorg-22.214.171.1241-10.20080314.fc9.x86_64 Also I most probably suspect the tpd as the primary source of troubles for xserver - just a wild guess...
Comment 11 Bug Zapper 2008-05-14 06:03:16 UTC
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 12 Bug Zapper 2009-06-09 23:45:58 UTC
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 13 Zdenek Kabelac 2009-06-11 08:59:41 UTC
IMHO bug could be closed - I do not observe this problem on F11.