Bug#613593: xserver-xorg-video-radeon: [regression] X fails to start

[Michel Dänzer]

On Mon, 2011-02-28 at 15:00 +0100, Stephen Kitt wrote: 
> On Tue, 22 Feb 2011 11:46:42 +0100, Michel Dänzer <daenzer at debian.org> wrote:
> > On Mon, 2011-02-21 at 22:03 +0100, Stephen Kitt wrote: 
> > > Investigating further, it turns out that X actually starts if it's
> > > started on its own (rather than via gnome-session). Starting xterm
> > > etc. works OK, it's after gnome-session starts that everything blows
> > > up. I started X under gdb and got the following backtrace when it
> > > segfaulted after gnome-session started:
> > 
> > Which window/compositing manager does your GNOME (3?) session use? If it
> > uses OpenGL, this might be one of the GLX/DRI2 drawable life cycle
> > issues about which there are a few reports upstream.
> 
> I'm using metacity, no compiz or such like in sight.
> 
> > > Program received signal SIGSEGV, Segmentation fault.
> > > 0xb7d4390c in _int_free (av=<value optimized out>, p=0x861c730) at
> > > malloc.c:4957 4957    malloc.c: No such file or directory.
> > >         in malloc.c
> > > (gdb) bt
> > > #0  0xb7d4390c in _int_free (av=<value optimized out>, p=0x861c730) at
> > > malloc.c:4957 #1  0xb7d46bbd in __libc_free (mem=0x861c738) at
> > > malloc.c:3739 #2  0x0808cc24 in RegionDestroy (pReg=0x861c738)
> > > at ../../dix/region.c:256 #3  0xb7a45f58 in exaHWCopyNtoN
> > > (pSrcDrawable=0x861b040, pDstDrawable=0x861cd20, pGC=0x0,
> > > pbox=0xbfffd74c, nbox=1, dx=-16, dy=0, reverse=0, upsidedown=0)
> > > at ../../exa/exa_accel.c:555
> > 
> > I fail to see what can go wrong with that region in exaHWCopyNtoN(), so
> > presumably this is an after-effect of a problem that occurred earlier,
> > e.g. memory corruption. If you can get the X server running in valgrind,
> > that might give a hint.
> 
> I'm attaching the valgrind log for Xorg; I'm not sure the options are
> appropriate, there's at least a hint of some things going wrong with memcpy()
> calls in the compositing code...

[...] 

> ==19774== Source and destination overlap in memcpy(0x5c84c70, 0x5c84c70, 408)
> ==19774==    at 0x40258E5: memcpy (mc_replace_strmem.c:497)
> ==19774==    by 0x49BD3EA: exaMemcpyBox (exa_migration_classic.c:59)
> ==19774==    by 0x49BD8C4: exaCopyDirty (exa_migration_classic.c:234)
> ==19774==    by 0x49BDDF3: exaCopyDirtyToFb (exa_migration_classic.c:298)
> ==19774==    by 0x49C0048: exaDoMigration_mixed (exa_migration_mixed.c:113)
> ==19774==    by 0x49BB75C: exaDoMigration (exa.c:1131)
> ==19774==    by 0x49C6E08: exaTryDriverComposite (exa_render.c:734)
> ==19774==    by 0x49C75C7: exaComposite (exa_render.c:1033)
> ==19774==    by 0x811E11C: damageComposite (damage.c:640)
> ==19774==    by 0x810F3BF: CompositePicture (picture.c:1710)
> ==19774==    by 0x49C6933: exaTrapezoids (exa_render.c:1181)
> ==19774==    by 0x810F0A7: CompositeTrapezoids (picture.c:1751)

The only way I think this could happen is if the UploadToScreen hook
fails. Indeed, I've only noticed now that you have 

        Option          "EXANoDownloadFromScreen" "on"
        Option          "EXANoUploadToScreen" "on"

in xorg.conf. Does it work better without these options? The driver
doesn't really support running without these hooks anymore.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer