On Thu, Sep 17, 2015 at 10:02:08PM +0200, Ludovic Courtès wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=92027
The segfault and the valgrind issue happen in different files, so they
do not seem to be related.
The code before the line where gdb places the error:
Program received signal SIGSEGV, Segmentation fault.
fast_fetch_r5g6b5 (iter=0xffff5e68, mask=0x0) at pixman-fast-path.c:2191
2191 t0 = ((sr << 16) & 0x00FF0000) | ((sg << 8) & 0x0000FF00) |
(gdb) bt
#0 fast_fetch_r5g6b5 (iter=0xffff5e68, mask=0x0) at pixman-fast-path.c:2191
is the following:
while ((w -= 2) >= 0)
{
uint32_t sr, sb, sg, t0, t1;
uint32_t s = *(const uint32_t *)src;
src += 2;
sr = (s >> 8) & 0x00F800F8;
sb = (s << 3) & 0x00F800F8;
sg = (s >> 3) & 0x00FC00FC;
sr |= sr >> 5;
sb |= sb >> 5;
sg |= sg >> 6;
t0 = ((sr << 16) & 0x00FF0000) | ((sg << 8) & 0x0000FF00) |
(sb & 0xFF) | 0xFF000000;
This looks perfectly safe; all treated variables are scalars, so the result
may be wrong, but cannot cause a segfault. A problem with optimisation in gcc?
Or gdb giving a wrong line number? Since pointers are dereferenced before and
after that line.
I also tried to cd into /tmp/nix-build-..., source the environment variables
and run "make check"; then all tests pass (but the build is for i686-linux
on an x86_64-machine, so maybe this does not mean much outside the guix build
container?).
Andreas
