X under valgrind?

[Jeremy Huddleston]

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*.)
> _______________________________________________
> xorg at lists.freedesktop.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: http://lists.freedesktop.org/mailman/listinfo/xorg
> Your subscription address: jeremyhu at freedesktop.org