Summary: | glXCreateContextAttribsARB returns invalid non NULL context | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Γιώργος Κυλάφας (Giorgos Kylafas) <gekylafas> |
Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED DUPLICATE | ||
Severity: | crash | CC: | diego.ml, martin.ruessler |
Priority: | NOR | Keywords: | drkonqi |
Version: | 4.11.2 | Flags: | thomas.luebking:
Mesa+
thomas.luebking: nouveau- |
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: |
kwin supportInformation with OpenGL 1.2
kwin supportInformation with OpenGL 2.0 kwin supportInformation with OpenGL 3.1 kwin supportInformation with XRender kwin --replace output New crash information added by DrKonqi glxinfo for my Intel card with Mesa 9.2 Patch to print what context is created |
Description
Γιώργος Κυλάφας (Giorgos Kylafas)
2013-08-30 07:29:12 UTC
This are two bugs for one. 1st a crash: ----------- This looks like a threading issue, but just to rule that out: do you have a program called "bleachbit" installed? 2nd a GL issue (?) causing "invisible" (black?) textures: --------------------------------------------------------- Please provide the ouput of "qdbus org.kde.kwin /KWin supportInformation" (With problematic settings, eg. prepend "sleep 30;" to get yourself 30s seconds to change settings before the command fires. Shift+Alt+F12 allows you to toggle the compositor on/off anytime) Also ensure to enable (1212) KWin in "kdebugdialog" and run "kwin --replace &" from konsole and watch out for GL errors/warnings. You'll get (much) more GL debug information by "export LIBGL_DEBUG=1", resp. "export LIBGL_DEBUG=verbose" Created attachment 82113 [details]
kwin supportInformation with OpenGL 1.2
Created attachment 82114 [details]
kwin supportInformation with OpenGL 2.0
Created attachment 82115 [details]
kwin supportInformation with OpenGL 3.1
Created attachment 82116 [details]
kwin supportInformation with XRender
Created attachment 82117 [details]
kwin --replace output
> Screens > ======= > Multi-Head: no > Number of Screens: 2 > Screen 0 Geometry: 0,0,1920x1080 > Screen 1 Geometry: 1920,0,1920x1080 Does it only happen with one screen? > Compositing > =========== > Qt Graphics System: native Does it happen with the raster graphicssystem? > Currently Active Effects: > ------------------------- > kwin4_effect_blur Does it happen with blurring disabled? (In reply to comment #7) > > Screens > > ======= > > Multi-Head: no > > Number of Screens: 2 > > Screen 0 Geometry: 0,0,1920x1080 > > Screen 1 Geometry: 1920,0,1920x1080 > > Does it only happen with one screen? It happens with only one screen as well. > > Compositing > > =========== > > Qt Graphics System: native > > Does it happen with the raster graphicssystem? Raster with OpenGL 2.0 does not crash kwin, but does not work either: windows lose their decorations and I cannot bring them to the foreground, I only see their borders when I click on the task bar. Raster with OpenGL 3.1 crashes kwin every time. > > Currently Active Effects: > > ------------------------- > > kwin4_effect_blur > > Does it happen with blurring disabled? The above (1 Screen, Raster) were tested with blur disabled. NOTE: This is my work computer and I will be out of office until the end of the week, so I won't be able to respond until next Monday. Created attachment 82645 [details]
New crash information added by DrKonqi
kwin (4.11.1) on KDE Platform 4.11.1 using Qt 4.8.5
- What I was doing when the application crashed:
Tried to switch from OpenGL 2.0 to OpenGL 3.1 on an updated Fedora 19.
I've got an Intel Graphics card:
00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express Integrated Graphics Controller (rev 10)
kernel-3.10.10-200.fc19.x86_64
mesa-dri-drivers-9.2-1.20130919.fc19.x86_64
Will try to provide the other informations that have been asked.
- Custom settings of the application:
Tried to set OpenGL 3.1.
-- Backtrace (Reduced):
#6 0x0000003d5cc35a19 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#7 0x0000003d5cc37128 in __GI_abort () at abort.c:90
#8 0x0000003d5cc2e986 in __assert_fail_base (fmt=0x7f5e1681f66f "%s%s%s:%u: %s%sasserzione \"%s\" non riuscita.\n%n", assertion=assertion@entry=0x3d5f0b0d08 "!xcb_xlib_threads_sequence_lost", file=file@entry=0x3d5f0b0b63 "xcb_io.c", line=line@entry=274, function=function@entry=0x3d5f0b1016 <__PRETTY_FUNCTION__.14368> "poll_for_event") at assert.c:92
#9 0x0000003d5cc2ea32 in __GI___assert_fail (assertion=assertion@entry=0x3d5f0b0d08 "!xcb_xlib_threads_sequence_lost", file=file@entry=0x3d5f0b0b63 "xcb_io.c", line=line@entry=274, function=function@entry=0x3d5f0b1016 <__PRETTY_FUNCTION__.14368> "poll_for_event") at assert.c:101
#10 0x0000003d5f041309 in poll_for_event (dpy=dpy@entry=0x9b1db0) at xcb_io.c:271
(In reply to comment #9) > Tried to set OpenGL 3.1. Oh, probably that's the problem: the driver reports is able only to do OpenGL 2.1, not 3.1. Created attachment 82646 [details]
glxinfo for my Intel card with Mesa 9.2
(In reply to comment #10) > Oh, probably that's the problem: the driver reports is able only to do > OpenGL 2.1, not 3.1. Yes, and the driver is correct about that. Neither of the chips in this bug supports GL 3.1 Looking at Giorgos support informations, i assume he encountered the original crash/backtrace on attempting to set GL 3.1 as well, while on GL 2.1 he "only" has the invisible texture issue. -> We could and maybe should invoke the detected GL platform version on creating the context, but glXCreateContextAttribsARB should return a NULL context for unsupported attribs, why this is very likely a driver bug - can anybody inject some patches to see where a non NULL context is returned? (In reply to comment #12) > -> We could and maybe should invoke the detected GL platform version on > creating the context, but glXCreateContextAttribsARB should return a NULL > context for unsupported attribs, why this is very likely a driver bug - can > anybody inject some patches to see where a non NULL context is returned? Given some time and a patch I can get that information. Is it something I can even debug with gdb setting a breakpoint without patching? > Given some time and a patch I can get that information. Is it something I
> can even debug with gdb setting a breakpoint without patching?
debugging is quite difficult. You must run from a tty and OpenGL might not work
then, because it's not the same VT.
I guess Thomas wanted to see whether the mentioned method is NULL and whether
the extension is supported.
Nope, i wanted to check which attribute gets us a non NULL context (what causes skipping the fallbacks) and whether it yells an error despite. glXCreateContextAttribsARB should be present since we'd had crashed before otherwise in dereferecing the function - but testing whether the context pointer is just the function pointer is a nice idea indeed. when i switch back to the 4.11 branch , I'll write you a patch to inject & try - as Martin pointed out debugging kwin with gdb is less pleasant (though possible) - and you'd likely need a gdwarf/ggdb compilation in order to inspect the stack anyway. Created attachment 82708 [details]
Patch to print what context is created
(In reply to comment #16) > Created attachment 82708 [details] > Patch to print what context is created Thank you. Will try the patch as soon as I can (busy life). Splitting bugs (and preemtively blaming mesa for not returning NULL) more info on the other bug *** This bug has been marked as a duplicate of bug 327310 *** |