X under valgrind?

[walter harms]

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