[Pixman] [BUG] SIGSEGV in sse2_fill

[Adam Jackson]

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.

> 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...

> 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.

- ajax