Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 517744

Summary: Xorg froze
Product: [Fedora] Fedora Reporter: Thomas Vander Stichele <thomas>
Component: xorg-x11-serverAssignee: Adam Jackson <ajax>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 12CC: mcepl, michiel, xgl-maint
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-03-03 18:33:13 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Thomas Vander Stichele 2009-08-16 15:01:15 UTC
Description of problem:

Was typing in a terminal and it froze.  Logged in from a different machine, got a backtrace from gdb:

(gdb) bt
#0  __lll_lock_wait_private ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:97
#1  0x0000003bc987cb1b in _L_lock_9857 () at hooks.c:126
#2  0x0000003bc987a7e7 in *__GI___libc_malloc (bytes=21) at malloc.c:3635
#3  0x0000003bc9405272 in local_strdup (
    s=0x7faf8c165337 "/lib64/libgcc_s.so.1") at dl-load.c:162
#4  0x0000003bc9408b8d in _dl_map_object (loader=0x7fafa0324000, 
    name=0x3bc99318fa "libgcc_s.so.1", preloaded=<value optimized out>, 
    type=<value optimized out>, trace_mode=<value optimized out>, 
    mode=-1879048191, nsid=0) at dl-load.c:2143
#5  0x0000003bc94130a9 in dl_open_worker (a=<value optimized out>)
    at dl-open.c:289
#6  0x0000003bc940e706 in _dl_catch_error (objname=<value optimized out>, 
    errstring=<value optimized out>, mallocedp=<value optimized out>, 
    operate=<value optimized out>, args=<value optimized out>)
    at dl-error.c:178
#7  0x0000003bc9412a27 in _dl_open (file=0x3bc99318fa "libgcc_s.so.1", 
    mode=-2147483647, caller_dlopen=0x0, nsid=-2, argc=9, argv=0x0, 
    env=0x7fffa8321e38) at dl-open.c:615
#8  0x0000003bc991b010 in do_dlopen (ptr=0x7fffa83212f0) at dl-libc.c:86
#9  0x0000003bc940e706 in _dl_catch_error (objname=<value optimized out>, 
    errstring=<value optimized out>, mallocedp=<value optimized out>, 
    operate=<value optimized out>, args=<value optimized out>)
---Type <return> to continue, or q <return> to quit---
    at dl-error.c:178
#10 0x0000003bc991b177 in dlerror_run (args=<value optimized out>, 
    operate=<value optimized out>) at dl-libc.c:47
#11 *__GI___libc_dlopen_mode (args=<value optimized out>, 
    operate=<value optimized out>) at dl-libc.c:160
#12 0x0000003bc98f3a75 in init () at ../sysdeps/ia64/backtrace.c:41
#13 0x0000003bca40c4f3 in pthread_once ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_once.S:94
#14 0x0000003bc98f3b74 in *__GI___backtrace (array=<value optimized out>, 
    size=32) at ../sysdeps/ia64/backtrace.c:79
#15 0x00000000004e89b6 in xorg_backtrace () at backtrace.c:39
#16 0x000000000047d63f in xf86SigHandler (signo=11) at xf86Events.c:385
#17 <signal handler called>
#18 _int_malloc (av=0x3bc9b69e80, bytes=24) at malloc.c:4311
#19 0x0000003bc987a7f2 in *__GI___libc_malloc (bytes=24) at malloc.c:3638
#20 0x00000000004d56d8 in miRectAlloc (pRgn=0x7a21c50, n=1) at miregion.c:378
#21 0x00007faf9efb1e61 in fbPixmapToRegion (pPix=<value optimized out>)
    at fbpixmap.c:249
#22 0x00000000004cda5c in miChangeClip (pGC=0x46eb6c0, type=1, 
    pvalue=0x46973a0, nrects=0) at migc.c:84
#23 0x000000000052dcc4 in damageChangeClip (pGC=0x46eb6c0, type=1, 
    pvalue=0x46973a0, nrects=0) at damage.c:551
#24 0x000000000045892f in dixChangeGC (client=<value optimized out>, 
---Type <return> to continue, or q <return> to quit---
    pGC=0x46eb6c0, mask=524288, pC32=0x9c1a058, pUnion=0x0) at gc.c:448
#25 0x0000000000445738 in ProcChangeGC (client=0x46e0830) at dispatch.c:1388
#26 0x0000000000446ee4 in Dispatch () at dispatch.c:437
#27 0x000000000042d0d5 in main (argc=<value optimized out>, 
    argv=0x7fffa8321de8, envp=<value optimized out>) at main.c:397
Current language:  auto; currently asm

strace continuously prints out this:
--- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigreturn(0xe)                       = -1 EINTR (Interrupted system call)
futex(0x3bc9b69e80, FUTEX_WAIT_PRIVATE, 2, NULL) = ? ERESTARTSYS (To be restarted)
--- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigreturn(0xe)                       = -1 EINTR (Interrupted system call)
futex(0x3bc9b69e80, FUTEX_WAIT_PRIVATE, 2, NULL) = ? ERESTARTSYS (To be restarted)
--- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigreturn(0xe)                       = -1 EINTR (Interrupted system call)
futex(0x3bc9b69e80, FUTEX_WAIT_PRIVATE, 2, NULL) = ? ERESTARTSYS (To be restarted)
--- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigreturn(0xe)                       = -1 EINTR (Interrupted system call)
futex(0x3bc9b69e80, FUTEX_WAIT_PRIVATE, 2, NULL^C <unfinished ...>


desktop is hung, going to kill it now



Version-Release number of selected component (if applicable):
xorg-x11-server-Xorg-1.6.1.901-1.fc11.x86_64

Comment 1 Adam Jackson 2009-08-19 19:18:48 UTC
Well that's embarassing.  backtrace_symbols() calls malloc, but we call it from a signal handler, so if malloc faults, we deadlock.  Now why malloc faulted, who knows.

Comment 2 Stefan Becker 2009-09-18 18:42:48 UTC
Duplicate of bug #517625?

I'm currently trying to get a gdb backtrace from my machine....

Comment 3 Stefan Becker 2009-09-18 19:41:31 UTC
I got a different backtrace. I've opened a new bug #524312 as in my case this seems to be caused by xorg-x11-drv-ati & EXA.

Comment 4 Matěj Cepl 2009-11-05 17:14:02 UTC
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages (at least F12Beta, but even better if the very latest versions).

Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.

If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]

Comment 5 Bug Zapper 2009-11-16 11:29:21 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 6 Michiel 2009-12-24 04:48:48 UTC
this is still happening a lot for me. Actually it started after upgrading to F12 (from F11, although clean install, not upgrade)

- running F12
- all packages updated until today (Dec 23) (using main and updates repos only)

1. every so often (hard to predict when), screen completely freezes and unable to go to console.
2. ssh-ing in from another machine works and finds Xorg on 100% CPU (sometimes even over)
3. reboot seems the only option

In the last few days has happened, at least a few times a day. I normally never reboot, only suspend.

Not sure how to provide more information, but next time, I'll see if the "(gdb) bt" option gives anything useful.

I have a Dual screen setup with my Laptop and external screen. Driver used is Radeon, nothing fancy

Comment 7 Matěj Cepl 2010-02-26 12:21:15 UTC
Could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[Note please, that this is machine generated comment for large amount of bugs; due to some technical issues, it is possible we've missed some of the responses -- it is happens, please, just a make a comment about that; that we will see. Thank you]

Comment 8 Michiel 2010-02-27 20:35:45 UTC
sure, close it. I'm afraid I can't provide any more data. After having used Redhat since version 5.2, I found myself forced to switch to Ubuntu (for now), as this problem made my work impossible. I had to force-reboot (hold power down) several times a day. I tried installing backtrace stuff (like Thomas describes), but I'm unfamiliar with how that works and I never got it to work.

Googling found that I'm not alone, but if you can't reproduce it, then yes, I can imagine you will need to close it "unable to reproduce".

Comment 9 Matěj Cepl 2010-03-03 18:33:13 UTC
So, I am sorry, we've lost that faithful friend of RH/Fedora distros, but apparently the situation hasn't changed much from comment 1. It is obvious there is a problem, but we have no clue where.

Closing as INSUFFICIENT_DATA but please reopen if you get any more information about it.

Good luck with Ubuntu!