Re: ‘core-updates’ freeze approaching!

[Andreas Enge <andreas@enge.fr>]

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