Description of problem: Looks like every OpenGL program causes segfault. Version-Release number of selected component (if applicable): mesa-libGL-9.0-0.2.fc18.i686 xorg-x11-server-Xorg-1.13.0-5.fc18.i686 xorg-x11-drv-intel-2.20.8-1.fc18.i686 glx-utils-7.10-8.20101028.fc18.i686 How reproducible: 100% Steps to Reproduce: 1. launch one program using GL 2. 3. Actual results: Just segfault, sometimes X crashes. Expected results: Does not segfault
Created attachment 619321 [details] /var/log/Xorg.0.log /var/log/Xorg.0.log /etc/x11/xorg.conf does not exist.
Created attachment 619322 [details] gdb log when lauching glxgears gdb log when launching glxgears as one example.
This clearly isn't affecting everyone, I had mesa 9.0 in the GFX Test Week images.
8086:3582:1179:0033 [ 67933.956] (--) intel(0): Integrated Graphics Chipset: Intel(R) 852GM/855GM Here's a quarter, kid, go buy yourself a real graphics card ;)
With mesa-libGL-9.0-1.fc18.i686, mesa-libGLU-9.0.0-1.fc18.i686: [tasaka1@localhost ~]$ glxgears X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 152 (GLX) Minor opcode of failed request: 3 (X_GLXCreateContext) Serial number of failed request: 28 Current serial number in output stream: 30 No segv, however still does not launch.
Created attachment 625554 [details] xorg.0.log again /var/log/Xorg.0.log this time
Proposing for a final blocker.
There have been no new reports or movement in this bug in over a month - is this still happening? Does it affect the operation of shell? I'm -1 blocker on this - it doesn't seem to be affecting enough hardware to justify blocking release until a fix is available. It doesn't sound like it affects general non-openGL operation of the system, either and could be fixed with an update post-install.
(In reply to comment #8) > There have been no new reports or movement in this bug in over a month - is > this still happening? No new reports = No improvement yet > Does it affect the operation of shell? I am using fallback mode.
-1 blocker, 855 is ancient stuff and GL-only breakage isn't worth blocking for. I believe 8xx is blacklisted for Shell purposes, so such cards get fallback mode, so there's no ootb breakage in critical functionality.
This seems to affect some critical component on GNOME such as gnome-control-center, like: [tasaka1@localhost ~]$ gnome-control-center (gnome-control-center:15657): Gdk-ERROR **: The program 'gnome-control-center' received an X Window System error. This probably reflects a bug in the program. The error was 'GLXBadContext'. (Details: serial 166 error_code 167 request_code 152 minor_code 6) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the GDK_SYNCHRONIZE environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Trace/breakpoint trap
-1 blocker, would be nice to fix of course.
-1 blocker. The age of the 855GM ... I would expect laptops with it are probably 5+ years old, and perhaps we might have a few folks running on old/spare hardware but I think the number would be very, very low. GL-only makes it even less blockery; comment 11 wrt gnome-control-center raises an eyebrow a bit but not getting the impression that it is a persistent issue...
Well, the real question is why it leads to the crash mentioned in comment #11. Could you provide backtrace for the non-GL apps too? It hits the "All applications listed under the Applications menu or category must start successfully" but as pointed by folks, it's probably not very common HW these days. -1 blocker
(In reply to comment #14) > Well, the real question is why it leads to the crash mentioned in comment > #11. Could you provide backtrace for the non-GL apps too? Well, why is backtrace for "non"-GL apps needed here (and for what non-GL apps do you want, for example)?
(Note that: $ ldd -r /usr/bin/gnome-control-center | grep GL libEGL.so.1 => /lib/libEGL.so.1 (0x410db000) libGL.so.1 => /lib/libGL.so.1 (0x41013000)
I count -5 blocker votes, moving to rejected.
My laptop does have an 82852/855GM Integrated Graphics device and glxgears and desktop effects (with KDE) fail with the upgrade from Fedora 17 to 18. It worked fine with Fedora 17. It does not help anyone to rush out a release that breaks usability for many users. The upgrade was on 01-29-13 and all packages were updated - so no fix yet available it seems.
I've already switched to use rawhide, and it seems that with mesa-9.1-0.1.fc19 GL programs seems to be working. Hopefully mesa 9.1 will be pushed into F-18 to fix this issue.
I (the original reporter) no longer uses F-18, and now using F-19, however with xorg-x11-server-1.14.0-1.fc19 and mesa-9.1-1.fc19 GL program seem to be working (at least xscreensaver gl hacks are working). Now it seems mesa-9.1-1.fc18 is going to be pushed into F18 stable, I hope someone can test this issue.
mesa 9.1-1.fc18 resolves this for me (on an old Dell inspiron 510m with an 855GM graphics). GL programs and the gnome-control-center which previously failed now working
mesa 9-1-1.fc18 fixed this problem on i82865G (IBM ThinkCentre), however the next update (9-1-3) apparently caused (I cannot verify this, since 9-1-1 is no longer available to me) weird problems with KDE (both 4.9 and 4.10 suffer). At random occassions during KDE session (usually, after some time, say 10-30 minutes) the control panel vanishes and window applications suddenly lose taskbars, it becomes impossible to switch focus, etc. Initially, I thought this to be a problem with KDE 4.10, so I downgraded it back to 4.9, no effect. Then downgraded Mesa to 9.0 - this helped immediately, however OpenGL applications begun to fail again. The problem appeared on 7 IBM ThinkCentre computers, 5 of them equipped with i82865G and two with i82915G/GV/910GL.
As - I am the original reporter - I no longer use F-18, now using F-19 - For me, F-19 mesa-libGL-9.1-3.fc19 seems to be working, once I close this bug.