Version-Release number of selected component: gnome-shell-3.9.92-1.fc21 Additional info: reporter: libreport-2.1.7 backtrace_rating: 4 cmdline: gnome-shell --mode=gdm crash_function: do_winsys_init executable: /usr/bin/gnome-shell kernel: 3.12.0-0.rc0.git26.1.fc21.x86_64 runlevel: N 5 type: CCpp uid: 42 Truncated backtrace: Thread no. 1 (10 frames) #0 do_winsys_init at radeon_drm_winsys.c:212 #1 radeon_drm_winsys_create at radeon_drm_winsys.c:617 #2 create_screen at target.c:11 #3 dri2_init_screen at dri2.c:888 #4 driCreateNewScreen at ../../../../src/mesa/drivers/dri/common/drisw_util.c:70 #5 driswCreateScreen at drisw_glx.c:686 #6 AllocAndFetchScreenConfigs at glxext.c:778 #7 __glXInitialize at glxext.c:879 #8 glXQueryVersion at glxcmds.c:487 #9 _cogl_winsys_renderer_connect at winsys/cogl-winsys-glx.c:770 Potential duplicate: bug 968436
Created attachment 798732 [details] File: backtrace
Created attachment 798733 [details] File: cgroup
Created attachment 798734 [details] File: core_backtrace
Created attachment 798735 [details] File: dso_list
Created attachment 798736 [details] File: environ
Created attachment 798737 [details] File: exploitable
Created attachment 798738 [details] File: limits
Created attachment 798739 [details] File: maps
Created attachment 798740 [details] File: open_fds
Created attachment 798741 [details] File: proc_pid_status
Created attachment 798742 [details] File: var_log_messages
Also occurs in F20: gnome-shell-3.10.2.1-2.fc20.x86_64 xorg-x11-server-Xorg-1.14.4-5.fc20.x86_64 Coincides with bug 1002513 as reported by libreport.
kernel 3.11.10-300.fc20.x86_64 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Whistler [Radeon HD 6630M/6650M/6750M/7670M/7690M] [1002:6741] (prog-if 00 [VGA controller])
Created attachment 833445 [details] core_backtrace
Created attachment 833447 [details] coredump.bz2
Created attachment 833448 [details] dmesg
I've got the same problem (sent here by abrt) in a multi-seat environment : -Primary seat uses "[AMD/ATI] Turks XT [Radeon HD 6670/7670]" -Secondary seat uses "[AMD/ATI] Juniper LE [Radeon HD 5670 640SP Edition]" The problem only happens on the secondary seat. Right now, I cannot use the secondary seat (or only without gnome...), so I'm very willing to help if you need any information to find this bug! Goulou.
By the way, I am running F20 (fully updated at this date). I have two additionnal comments : -I think the bug is identical to this one : https://bugzilla.redhat.com/show_bug.cgi?id=985994 -I think the bug is more related to the radeon driver than to gnome-shell or gnome-session. (see message : segfault at 0 ip 00007fc85c738e59 sp 00007fffb84d4ba0 error 4 in r600_dri.so[7fc85c390000+5e1000] ) I don't think I can change the assignment, so if someone can do it, it would be a good idea. Thanks for everything.
Well, I nailed down the problem a bit. First, a list of clone bugs (not all of them, Google "do_winsys_init at radeon_drm_winsys.c" and you'll find many others...) : https://bugs.freedesktop.org/show_bug.cgi?id=68085 https://bugzilla.redhat.com/show_bug.cgi?id=1021220 https://bugzilla.redhat.com/show_bug.cgi?id=1042936 https://bugzilla.redhat.com/show_bug.cgi?id=968436 One of the most important : https://bugs.freedesktop.org/show_bug.cgi?id=72732
(sorry for the repetition, I sent the form by mistake) Well, I nailed down the problem a bit. First, a list of clone bugs (not all of them are reported here, Google "do_winsys_init radeon_drm_winsys.c" and you'll find many others...) : https://bugs.freedesktop.org/show_bug.cgi?id=68085 https://bugzilla.redhat.com/show_bug.cgi?id=1021220 https://bugzilla.redhat.com/show_bug.cgi?id=1042936 https://bugzilla.redhat.com/show_bug.cgi?id=968436 Two of the most important : https://bugs.freedesktop.org/show_bug.cgi?id=72732 https://bugzilla.redhat.com/show_bug.cgi?id=993463 Then, a related patch http://lists.freedesktop.org/archives/mesa-dev/2013-October/047295.html To put it in a nutshell, the problem, is the call to drmGetVersion(). In our case, it fails (it returns NULL), and the next line makes the segfault. However, I found an *UGLY* workaround : changing the permissions on /dev/dri/cardX, where X is your video card number (in my case, X=1), so that the user where it fails can access it. In my case, a chown is enough (my 2nd seat always has the same user connected to it). I'm not sure why the call to drmGetVersion returns NULL : maybe this call should only be performed by a user that has the correct rights? Or, as suggested in #993463, the fd may be NULL (because the user has no right to open the device). But why do gnome-shell, gnome-session, control-center, and others trigger that code...? If somebody could reaffect this bug to the correct component (I would say "mesa" ?), this would be very nice of him. Thanks for your help, and I hope those findings are relevants! Goulou
Hi Frederic, Thanks for the digging. For me (as per my bug 993463/fdo 72732) this triggers when for some reason you start a GLX app when you have the wrong permissions on the /dev/drm/card* Now I was going to suggest a simple NULL check test (which is what all the non-radeon ones have) but that patch you've found is a lot hairier and actually requires understanding the driver.
Considering another bug I opened (https://bugzilla.redhat.com/show_bug.cgi?id=1052747), I'm not sure the problem lies in r600_dri.so code : there may be (at least in my case) a more general permission problem. However, I do think that the NULL check is unavoidable, so that at least the code path fails "gracefully", eventually having enough time to send logs. Frederic.
Frederic: Well in my case I understand why the permissions were wrong and it was my fault for not understanding the Fedora way of handling VTs; so the only problem is it should fail gracefully or fallback to non-dri stuff. The question then is how are you getting it into a situation where the perms are wrong; the other report I've seen is a 'machine was in a funny state after another problem' type of thing, mine was running two X servers and manually switching between VTs; how do you trigger yours?
As you can see in the other bug (#1052747), my permission problem is certainly due to my multi-seat configuration. The problem is being investigated in this context. However, I agree with you that, whatever created the problem, it should fail gracefully, not with a segfault... Frederic.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.