Bug 22794

Created attachment 27755 [details]
Xorg log

Can you try with pixman-0.15.14?

Another thing that would be useful is if in frame #9, you could 

   print pSrc->pDrawable->type 

and in frame #5, if you could

   print *(src->bits)
   print *(dest->bits)

Thanks.
   

I just tried pixman-0.15.14 and it works. I'll try later to switch back to git master and provide the info you requested.

When compiling pixman git master again, please compile it without optimization, but with debug. Ie., 

    env CFLAGS="-g -O0" ./autogen.sh ...

Bisecting would also be helpful.  I'm somewhat mystified as to what is going on here.

Created attachment 27787 [details]
gdb trace new

(In reply to comment #3)
> Another thing that would be useful is if in frame #9, you could 
> 
>    print pSrc->pDrawable->type 
> 
> and in frame #5, if you could
> 
>    print *(src->bits)
>    print *(dest->bits)
> 
> Thanks.
> 
> 

Please find attached (gdb trace new) the gdb trace providing such info. I compiled git master without optimization (as I did the first time, too).

While playing with gcc-related Debian packages, I discovered that by removing libc6-i686 makes VT switching work even with git master. I installed and removed such package ("optimized for i686") several times to be sure and the result is that VT switching always works with pixman-0.15.14 (with or without libc6-i686), while it only works with pixman git master if libc6-i686 is *not* installed.

Do you still want me to git-bisect when libc6-i686 is installed?

I am beginning to suspect something other than pixman is causing this, but yes, please do bisect with the i686 glibc installed.

Also a 

   cat /proc/<pid of X server>/maps 

could be useful. (You'll need to be root, or it won't print anything).

It would be interesting to know whether this still happens in 0.15.18.

I just rebuilt the whole Xorg stack from scratch and *looks like* this issue is gone. I'll let you know after some more testing, thanks.

Well, crashes somehow randomly happen, thus making it difficult to say whether it "works" or not. What I can say now is that with the latest git of everything (and a rebuild), it is "more" difficult to make X crash by VT-switching, meaning that I am sometimes able to switch VT multiple times without crashing the X server. 

However, I found a "reliable" way to cause a crash: when changing resolution of the screen with xrandr (back and forth between 1280x800 and 1024x768), VT switching soon makes X crash (attached gdb trace and Xorg maps). This happens both with pixman 0.15.14 and 0.15.18.

I also found that compositing affects this problem. I disabled KDE4 composited effects and found that it is much more difficult to cause X crashes with pixman 0.15.18. I also tried once with pixman 0.15.14 and was unable to provoke a crash. This seems to be in agreement with the fact that, with the Xorg stack from the experimental debian packages (xserver 1.6.2 and pixman 0.15.14), I have never reproduced this issue (when running debian's X server - I don't know why - I am not able to enable composited effects).

If time permits, I will bisect pixman without compositing. 

Created attachment 27976 [details]
Xorg maps

Created attachment 27977 [details]
yet another gdb trace

I wonder if it's possible to run Xorg under valgrind to check if it manages to spot anything suspicious much earlier than the crash happens.

Shall I use particular tools/options or is 'valgrind Xorg' enough?

Maybe it would be the best if you could run your full desktop with Xorg running under valgrind. If there are some heap corruption problems or use after free or whatever else, valgrind may provide some useful info.

I used to run Xephyr under valgrind for debugging some stuff, and it proved to be quite efficient. Don't know how well it would run with full KDE desktop, but probably it is worth trying.

Just standard memcheck tool should be enough, maybe redirecting its output to some file may be handy too.

See also

     https://bugzilla.redhat.com/show_bug.cgi?id=518585

This looks like a problem with the intel driver.

Is this still with 2.8.1 release?

Yes, it is still present with the latest git master of everything. The Xorg backtrace is still the same. Please let me know if I can do anything to help.

xorg xserver 1.6.99.900, intel driver git, pixman 0.16, all other xorg packages in latest released versions (built from tarball), kernel 2.6.31git + drm-intel-next branch merged.

Linux 86_64

Backtrace:
0: /usr/bin/X (xorg_backtrace+0x28) [0x45f238]
1: /usr/bin/X (0x400000+0x62819) [0x462819]
2: /lib64/libpthread.so.0 (0x7fe27a40b000+0xeb70) [0x7fe27a419b70]
3: /usr/lib64/libpixman-1.so.0 (0x7fe27aa77000+0x4994c) [0x7fe27aac094c]
4: /usr/lib64/libpixman-1.so.0 (0x7fe27aa77000+0x37882) [0x7fe27aaae882]
5: /usr/lib64/libpixman-1.so.0 (0x7fe27aa77000+0x38966) [0x7fe27aaaf966]
6: /usr/lib64/libpixman-1.so.0 (0x7fe27aa77000+0x4417f) [0x7fe27aabb17f]
7: /usr/lib64/libpixman-1.so.0 (pixman_image_composite+0x17c) [0x7fe27aaa756c]
8: /usr/lib64/xorg/modules/libfb.so (fbComposite+0x163) [0x7fe277460ab3]
9: /usr/lib64/xorg/modules/drivers/intel_drv.so (0x7fe277875000+0x5e69b) [0x7fe2778d369b]
10: /usr/lib64/xorg/modules/drivers/intel_drv.so (0x7fe277875000+0x5cc1e) [0x7fe2778d1c1e]
11: /usr/bin/X (0x400000+0xd1650) [0x4d1650]
12: /usr/bin/X (0x400000+0xcb29e) [0x4cb29e]
13: /usr/bin/X (0x400000+0x2cbcc) [0x42cbcc]
14: /usr/bin/X (0x400000+0x2224c) [0x42224c]
15: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x7fe2796aaa9d]
16: /usr/bin/X (0x400000+0x21df9) [0x421df9]
Segmentation fault at address 0x7fe2762b275c

will attach gdb traces soon

I can't reproduce this with kde 4.3.1, and upstream git master for kernel, xorg, and mesa_7_6_branch, on T61 965GM here.

Could you validate if this still exists on your side?

Looks like this issue is gone with the recent git master. I will do some more testing and report the results later.

BTW, I noticed a regression introduced with the recent git master. The World Clock plasmoid does not work anymore. If you try to add it, plasma-desktop crashes as soon as you try to close the add widget window. If you log in as a user that already has this plasmoid on the desktop (e.g., because he added it previously using xserver 1.6, mesa 7.5, intel 2.8.1), the login process does not complete, meaning that the wallpaper is not painted, the desktop panel does not work, etc.

Since you also have kde 4.3.1, could you please tell me if you can reproduce this issue?

thanks

closing -- submitter reported it fixed.