[Pixman] [BUG] SIGSEGV in sse2_fill

[Frédéric Fauberteau]

Le 2018-08-29 16:33, Adam Jackson a écrit :
> On Wed, 2018-08-29 at 10:59 +0200, Frédéric Fauberteau wrote:
>> I encounter a xorg segfault after building it with the following
>> optimization CFLAGS: -march=athlon64-sse3 -mfpmath=sse
> 
> This is almost certainly a bug in either the radeon driver or in the X
> server. pixman is usually innocent in backtraces like this, as it just
> draws where it's told to.

Sure, it makes sense. Sorry, pixman was the last suspect on top of 
backtrace stack ;)

>> I noticed that height goes from 1050 in _pixman_implementation_fill() 
>> to
>> 1041 in sse2_fill() ...?
> 
> It happened to fill nine rows of pixels before segfaulting. There's
> probably no deep or numerological reason for this, other than: the
> place where xserver told pixman to start drawing, happened to be about
> that far away from unmapped memory.
> 
> This is a curious backtrace though. You're crashing while trying to
> draw the black solid fill for the initial map of the root window. Fine,
> but you're doing so in software, even though you have glamor enabled,
> and glamor surely can usually accelerate solid fills. So you're hitting
> a software fallback for some reason, and if I had to guess...

The area to fill is 2960x1050 but actually, I have two screens:
----------------- -------------
|               | |           |
|               | |           |
|   1680x1050   | | 1280x1024 |
|               | |           |
|               | |-----------|
-----------------

Do you think it could be a reason to write in an unmapped region...?

>> Program received signal SIGSEGV, Segmentation fault.
>> sse2_fill (imp=<optimized out>, bits=<optimized out>, 
>> stride=<optimized
>> out>, bpp=<optimized out>, x=<optimized out>, y=<optimized out>,
>> width=2960, height=1041, filler=0) at pixman-sse2.c:3408
> 
> ... that width number is where I'd start guessing. You don't say what
> radeon this is, but for some old ones (R300-ish if memory serves, I
> don't remember where in Mesa to look it up) that's wider than the 3D
> engine can draw to. That would explain the fallback, and it would
> suggest that even if the crash were fixed the interactive experience
> would be miserably slow.

It is a RS780/RS880 (Radeon HD 3200). If the bug comes from the Mesa 
driver, it's a big issue since we are totally late with the update (we 
are on MesaLib 11.2.2)

> - ajax

Fred