Bug 437504

(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?

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 ?

(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.

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.

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.

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.

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

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?

Chmm, so I can reproduce it, but only when gdb is not attached to the Xorg
process :-(

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-1.4.99.901-10.20080314.fc9.x86_64

Also I most probably suspect the tpd as the primary source of troubles for
xserver - just a wild guess...

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

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

IMHO bug could be closed - I do not observe this problem on F11.

Closing as per comment #13.