Xorg segmentation fault when drawing PolyArcs (under kicad)

[Renato Caldas]

2009/10/21 Renato Caldas <seventhguardian at gmail.com>:
> 2009/10/20 Renato Caldas <seventhguardian at gmail.com>:
>> 2009/10/20 Renato Caldas <seventhguardian at gmail.com>:
>>> Hello,
>>>
>>> Thanks for looking into this!
>>>
>>> 2009/10/20 Michel Dänzer <michel at daenzer.net>:
>>>> 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
>>>
>>
>