2009/10/21 Renato Caldas <[email protected]>: > 2009/10/20 Renato Caldas <[email protected]>: >> 2009/10/20 Renato Caldas <[email protected]>: >>> Hello, >>> >>> Thanks for looking into this! >>> >>> 2009/10/20 Michel Dänzer <[email protected]>: >>>> On Mon, 2009-10-12 at 20:12 +0100, Renato Caldas wrote: >>>>> Hello, >>>>> >>>>> First of all, I'm not subscribed to this list, so please include my >>>>> e-mail in the CC. >>>>> >>>>> When using (trying to use...), kicad I managed to get consistent Xorg >>>>> segmentation faults. I've filed a bug report on fedora's bugzilla: >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=528475. There I've >>>>> included a very basic test case that works all the time. In the >>>>> meantime, I've also got my hands dirty, and tried to debug Xorg using >>>>> gdb. >>>>> >>>>> The symptom is that the function fbBltOne is called with src=0x0, so >>>>> Xorg segfaults as soon as it tries to use src (in LoadBits; at >>>>> fb/fbbltone.c:292). >>>>> >>>>> I've traced its value back to fbPushPixels, where it is created and >>>>> fed to the function chain, in the macro fbGetStipDrawable (defined at >>>>> fb/fb.h:720). >>>>> >>>>> Here pDrawable->type seems to be DRAWABLE_PIXMAP, so _pPix is simply >>>>> cast from pDrawable. Then the _pPix -> devPrivate.ptr is used as >>>>> "src", after a couple of castings and copying around. >>>> >>>> Please provide a full backtrace ('bt full' in gdb) from when the crash >>>> occurs. >>> >>> Attached. I've also attached it to the bug report, just in case. >>> >>>> If you're using EXA, the problem is most likely that some code path >>>> isn't calling exaPrepareAccess(Reg) for the pixmap in question before >>>> calling down to the fb module. > > It seems that the code path is calling exaPrepareAccess: > > in ExaCheckPolyArc: > > (...) > exaPrepareAccess (pDrawable, EXA_PREPARE_DEST); > exaPrepareAccessGC (pGC); > pGC->ops->PolyArc (pDrawable, pGC, narcs, pArcs); > (...) > > but there's possibly something wrong there.
You're right, I found the problem, and it seems to be tricky! It seems that the scratch buffers used by a lot of functions never call exaPrepareAccess. I've created a small test program, and it never crashed. It turned out that kicad used a "GXor" operation, which was flagged as "tricky", requiring a scratch buffer. This scratch buffer would then be used without "preparation". There are a lot of functions that create a scratch buffer, but they're possibly rarely used: $ grep CREATE_PIXMAP_USAGE_SCRATCH * -lR dix/glyphcurs.c exa/exa_glyphs.c hw/xfree86/xaa/xaaInit.c include/scrnintstr.h mi/miarc.c mi/midispcur.c mi/mibitblt.c mi/miglblt.c render/render.c render/glyph.c render/mirect.c Xext/mbuf.c Xext/shm.c Xext/mbufpx.c Some of them may be safe, but at least the mi/ files should be fixed. The "tricky" part of the problem is how to call exaPrepareAccess in a clean way. fbPrepareAccess calls the driver's "PrepareAccess", so it seems to be the correct solution. But it shouldn't be called directly either, so I first need to put fbPrepareAccess in the *pGC->ops. Does this sound ok? Cheers, Renato > > Cheers, > Renato > >>> I am using EXA. I'll try enabling XAA and report back. >> >> Nouveau doesn't support XAA, but I've disabled the acceleration. It >> doesn't crash anymore, so you must be correct :) I'll try to figure >> out a patch. >> >> Everything is slow now, but at least I can do some work. Thanks! >> >> Cheers, >> Renato >> >>> Thanks, >>> Renato >>> >> > _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
