Jeremy Huddleston schrieb: > I have a bunch of reports of this on version 1.4.2-apple53 as well (which > cherry picked changes to support the new libXfont), so it probably reduces > down to something in those change which were cherry picked. That's not much > help, but it looks like it probably landed in late 2008 or early 2009... > > 30 libSystem.B.dylib: usleep$NOCANCEL + 0 > 36 libSystem.B.dylib: __semwait_signal_nocancel + 10 > 36 libSystem.B.dylib: nanosleep$NOCANCEL + 129 > 36 libSystem.B.dylib: usleep$NOCANCEL + 57 > 66 libSystem.B.dylib: abort + 93 > 66 libSystem.B.dylib: free + 128 > ==> 66 libXfont.1.dylib: FontFileFreeEntry + 107 <== > 66 libXfont.1.dylib: FontFileFreeTable + 36 > 66 libXfont.1.dylib: FontFileFreeDir + 21 > 66 libXfont.1.dylib: FontFileFreeFPE + 26 > 66 X11.bin: FreeFPE + 43 > 66 X11.bin: FreeFontPath + 101 > 66 X11.bin: FreeFonts + 55 > 66 X11.bin: dix_main + 1486 > 66 X11.bin: server_thread + 50 > 66 libSystem.B.dylib: _pthread_start + 331 > 66 libSystem.B.dylib: thread_start + 13 > > > Application Specific Information: > abort() called > X.Org X Server 1.4.2-apple53 Build Date: 20100211 > > > On Oct 20, 2010, at 13:11, Nix wrote: > >> I'm trying to track down a strange bug in X 1.9.0.901 (and probably .902 >> as well), whereby after a suspend/resume cycle long enough to time out >> nonlocal TCP connections, my X server crashes the first time I map an >> XEmacs window (probably 'the first thing that uses core fonts at all') >> with this unhelpful backtrace: >> >> Backtrace: >> 0: X (xorg_backtrace+0x28) [0x49b7d8] >> 1: X (0x400000+0x5dde9) [0x45dde9] >> 2: /lib/libpthread.so.0 (0x7f50fc27f000+0xe9b0) [0x7f50fc28d9b0] >> 3: /lib/libc.so.6 (0x7f50fb1f3000+0x731c0) [0x7f50fb2661c0] >> 4: /lib/libc.so.6 (cfree+0x6c) [0x7f50fb269abc] >> 5: /usr/lib/libXfont.so.1 (FontFileFreeEntry+0x8f) [0x7f50fbdf12ef] >> 6: /usr/lib/libXfont.so.1 (FontFileFreeTable+0x2e) [0x7f50fbdf136e] >> 7: /usr/lib/libXfont.so.1 (FontFileFreeDir+0xd) [0x7f50fbdf139d] >> 8: /usr/lib/libXfont.so.1 (FontFileFreeFPE+0x12) [0x7f50fbdf4692] >> 9: X (0x400000+0x2d04b) [0x42d04b] >> 10: X (0x400000+0x2fa8b) [0x42fa8b] >> 11: X (ProcessWorkQueue+0x21) [0x4307e1] >> 12: X (WaitForSomething+0x82) [0x456f72] >> 13: X (0x400000+0x2bf92) [0x42bf92] >> 14: X (0x400000+0x209ee) [0x4209ee] >> 15: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7f50fb211d6d] >> 16: X (0x400000+0x205a9) [0x4205a9] >> Segmentation fault at address 0xffffffff0241b148 >> >> gdb is not much more helpful (I mean, yes, obviously we have a >> double-free(), but why? something to do with the font server I've got at >> the end of the font path specifically to trip bitrot like this, I >> suppose), so I'm planning to valgrind it... but I'm a bit chary of that >> because the last time I valground the X server, horrible disasters >> resulted which ended in a system lockup and massive filesystem >> corruption. Of course, that was before the era of KMS: perhaps things >> are better now that X hardly touches the hardware. >> >> So... has anyone ever valground the X server? Does it work? (Of course >> it will be slow. I'm expecting *that*.)
can you see what is freed ? perhaps you can grep the code to see if that is used somewhere else, then setting the variable there to NULL. If this is not happening with X 1.9.0. <901 the most easy way is to use git-biset. hope that helps, re, wh _______________________________________________ [email protected]: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: [email protected]
