On Thu, Mar 25, 2010 at 5:43 PM, Ruediger Oertel <r...@suse.de> wrote: > On Friday 26 March 2010 00:22:00 Ruediger Oertel wrote: >> On Thursday 25 March 2010 22:55:13 Timo Aaltonen wrote: >> > >> yes, for some reason it does not happen with the intel driver (or >> > >> probably other combinations with only one native driver plus fbdev and >> > >> vesa). Maybe that's a way to look: something in the screen setup may >> > >> be different for fbdev or vesa, I'll try to look later on. >> > >> >> > >> my simple test to reproduce is just starting the xserver plus an xterm >> > >> on it and then exiting the xterm. >> > > >> > > Crap, sounds like I need to try in on the desktop with nouveau/blob/nv >> > > :) >> > >> > Still no crash even with that machine. Tried several different scenarios: >> > >> > - nvidia loaded (nouveau blacklisted), nv/nouveau available/missing >> > - nouveau loaded, nv/nvidia available/missing >> > >> > so I guess that leaves hybrids like intel/ati, intel/nvidia, ati/nvidia >> > that are crashing? >> >> argh, I apologize for leaving one important fact aside: >> I'm running with malloc checking on: >> # set | grep MALLOC >> MALLOC_CHECK_=3 >> MALLOC_PERTURB_=69 >> >> if I unset MALLOC_PERTURB_, the Xserver will run pretty happily without >> crashing on cleanup. still I'm pretty sure it's a valid problem as I'm >> producing structures that will cause a double-free on cleanup. > > sigh ... and once I had realized this, I played with that some more: > result: > - the patch does pretty sure not cause the segfault > - backed out my patch, rebuilt, run with MALLOC_* set and get the crash > - backed out all distro patches, rebuilt xorg-server-1.7.99.902.tar.bz2 > and still see the crash (config with driver="nouveau" selected) > in other words: the machines with the intel driver where I thought I could > not reproduce the crash on, most likely did not have MALLOC_* set > > and I've spent almost two days chasing a segfault in my patch without > even realizing it was elsewhere ...
Heh, I'm sure everyone's done that at least once. :) > so IMHO here are two things: > - please continue the review of my patch for possible inclusion Yeah, the last patch looked good to me. Reviewed-by: Dan Nicholson <dbn.li...@gmail.com> > - does anyone have an idea what's causing this crash with the vanilla xserver: > Backtrace: > 0: ./xorg-server-1.7.99.902/hw/xfree86/Xorg (xorg_backtrace+0x28) [0x462148] > 1: ./xorg-server-1.7.99.902/hw/xfree86/Xorg (0x400000+0x65f69) [0x465f69] > 2: /lib64/libc.so.6 (0x7fb4e3122000+0x329f0) [0x7fb4e31549f0] > 3: ./xorg-server-1.7.99.902/hw/xfree86/Xorg (0x400000+0x15edff) [0x55edff] > 4: ./xorg-server-1.7.99.902/hw/xfree86/Xorg (TraverseTree+0x85) [0x443d25] > 5: ./xorg-server-1.7.99.902/hw/xfree86/Xorg > (RRDeleteAllOutputProperties+0x6e) [0x55eefe] > 6: ./xorg-server-1.7.99.902/hw/xfree86/Xorg (0x400000+0x9caab) [0x49caab] > 7: ./xorg-server-1.7.99.902/hw/xfree86/Xorg (FreeClientResources+0xd3) > [0x456db3] > 8: ./xorg-server-1.7.99.902/hw/xfree86/Xorg (FreeAllResources+0x49) [0x456e89] > 9: ./xorg-server-1.7.99.902/hw/xfree86/Xorg (0x400000+0x25b11) [0x425b11] > 10: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x7fb4e3140b7d] > 11: ./xorg-server-1.7.99.902/hw/xfree86/Xorg (0x400000+0x25699) [0x425699] > Segmentation fault at address (nil) > > Fatal server error: > Caught signal 11 (Segmentation fault). Server aborting > > as it may be related: > gcc --version > gcc (SUSE Linux) 4.5.0 20100311 (experimental) [trunk revision 157384] > > CFLAGS='-O2 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector > -funwind-tables -fasynchronous-unwind-tables -g -fno-strict-aliasing' > ARCH=x86_64 Maybe we should open a separate bug for that one and specify that it gets triggered by MALLOC_PERTURB_. Someone familiar with the randr code might be able to dig out the cause. -- Dan _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
