Interesting. Thanks for the report. I'll take a look.

If you configure pixman-0.26.0 with --disable-loongson-mmi, can you reproduce your problem?

Good point. Disabling the FPU vector optimizations specific for Loongson helped. (I thought they have been merged after 0.26.0 release.)

I compile with CFLAGS="-O2 -march=loongson2f -mabi=n32 -pipe -mplt -Wa,-mfix-loongson2f-nop" LDFLAGS="-Wl,-O1 -Wl,--as-needed" using GCC-4.6.3 and binutils-2.22. I have "ICT Loongson-2 V0.3  FPU V0.1" processor.

To Petr Pisar: Could you try to compile and run the following simple test program (with -O2 optimizations)?

    #include <stdio.h>
    #include <stdlib.h>
    #include <unistd.h>
    #include <time.h>
    #include <signal.h>
    #include <string.h>
    #include <sys/time.h>
     
    void alarm_handler(int a)
    {
            volatile double d1 = 1.1, d2 = 2.2, d3;
            d3 = d1 + d2;
            printf(".\n");
            alarm(1);
    }
     
    int main(int argc, char **argv)
    {
            volatile double d = 1.5;
            signal(SIGALRM, alarm_handler);
            alarm(1);
            while (d == 1.5) {}
            printf("we should not be here\n");
            return 0;
    }

(In reply to comment #4)
> To Petr Pisar: Could you try to compile and run the following simple test
> program (with -O2 optimizations)?
> 
It works flawlessly.

I cannot reproduce this issue with pixman-0.27.2.

Notice 1: It's possible the lock-up was caused by X server killed by kernel due to the bug in the pixman. This puts the virtual console into dead state usually.

Notice 2: If I find SIGILLing application on the Loongson, it usually turn outs the compiler optimizes float arithmetics to multiply-and-add instruction which causes FPU exception if the factor register contains not-a-number (e.g. a result of previous division by zero).

(In reply to comment #6)
> I cannot reproduce this issue with pixman-0.27.2.
> 
> Notice 1: It's possible the lock-up was caused by X server killed by kernel
> due to the bug in the pixman.

It's more like the lock-up is caused by the kernel failing to correctly save/restore FPU state on context switches, causing FPU registers to contain unpredictable/corrupted values and various bad things happening. If 'make check' test passes for pixman on your machine, then the culprit is almost certainly your kernel.

The X server itself is a bit unique in the way it does input handling: http://ajaxxx.livejournal.com/62378.html
The code from comment 4 was an adapted variant of the testcase intended to reproduce the issue with *very* similar symptoms on ARM a long time ago (dragging cursor means that a lot of input handling and drawing via pixman is happening at the same time): https://bugs.launchpad.net/ubuntu/+source/linux-fsl-imx51/+bug/507503
Even though the test seemed to work on your machine, no real conclusions can be made yet. In any case you need to debug the issue and identify the root cause of it yourself. Or wait for somebody else to successfully reproduce the problem. Good luck.

Nobody can reproduce this anymore, so I'm closing the bug. If the issue resurfaces, feel free to reopen.