[ANNOUNCE] xorg-server 1.7.99.902

[Dan Nicholson]

On Thu, Mar 25, 2010 at 5:43 PM, Ruediger Oertel <ro at 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.lists at 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