Bug 548413 - X server crash due to assertion failure in pixman-region.c
Summary: X server crash due to assertion failure in pixman-region.c
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: pixman
Version: 12
Hardware: x86_64
OS: Linux
low
high
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-12-17 11:58 UTC by Ian Collier
Modified: 2010-01-22 10:33 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-01-17 20:02:26 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
backtrace of crashed X server (2.87 KB, text/plain)
2009-12-17 11:58 UTC, Ian Collier
no flags Details
Another backtrace with slightly more debugging info (4.24 KB, text/plain)
2009-12-17 19:37 UTC, Ian Collier
no flags Details
Program that will crash the X server (309 bytes, text/x-csrc)
2009-12-18 14:35 UTC, Ian Collier
no flags Details

Description Ian Collier 2009-12-17 11:58:31 UTC
Created attachment 378970 [details]
backtrace of crashed X server

Description of problem:
I am getting logged out because of X server crashes, typically 2-10 minutes after starting xlockmore.  It seems fairly random (and I don't think there's a specific xlock mode that causes it).  Xorg.0.log shows no sign at all of the crash (so it's not attached).

Attaching gdb to the running X server showed that the crash is due to an assertion failure in the pixman library.  A backtrace is attached.  (In my opinion, (a) the X server should never allow itself to be killed by an assertion failure, and (b) if it does, it should produce a trace in the log.  Something needs to be fixed there.)

(Then I typed "gcore" into gdb and that's when the whole system locked solid - not even Alt+SysRq+b would work.)

The trace doesn't seem that useful as all the data is optimized out.  I've recompiled pixman without optimization and will attach another backtrace if it crashes again.  Any pointers as to what to look out for at that time would be welcome.

Version-Release number of selected component (if applicable):
pixman-0.16.2-1.fc12.x86_64
xorg-x11-server-Xorg-1.7.1-7.fc12.x86_64

How reproducible:
It's happened four or so times since I installed F12 ten days ago.

Steps to Reproduce:
1. Work on the computer
2. Run "xlock -mode random" and go to lunch
3. Come back to find the login screen instead of the logged in session

Comment 1 Ian Collier 2009-12-17 19:37:22 UTC
Created attachment 379079 [details]
Another backtrace with slightly more debugging info

I didn't have to wait long.

The crash occurs while xlock is doing a "losira" style erase (about line 742 of xlock/erase.c) and seems to result from executing:

XCopyArea(dpy,window,window,gc,736,0,0,1132,737,0)

It's not documented anywhere that it's illegal to call XCopyArea with a zero width, so either this assertion is wrong or the X server should treat the operation as a no-op before pixman gets involved.

Comment 2 Ian Collier 2009-12-18 14:35:51 UTC
Created attachment 379222 [details]
Program that will crash the X server

So here's a short C program with just that call in it; I tested it on another F12 box and it killed the X server instantly.

Comment 3 Søren Sandmann Pedersen 2010-01-17 20:02:26 UTC
Thanks for the bug report. I believe this is fixed in pixman 0.16.4.

Please feel free to reopen if it isn't.

Comment 4 Ian Collier 2010-01-22 10:33:06 UTC
Confirm that the program from comment 2 no longer crashes the X server after updating pixman.


Note You need to log in before you can comment on or make changes to this bug.