Xephyr as shipped in F-12 claims to support GLX 1.4, but really it only supports 1.2 (I think?). This causes "gnome-shell --xephyr" to fail now, because clutter 1.2 now uses GLX 1.3-specific features if the server claims to support 1.3. (http://bugzilla.openedhand.com/show_bug.cgi?id=2028). The problem is in either xserver-1.7.0-glx-versioning.patch or xserver-1.7.1-glx14-swrast.patch, or both, which I guess need to be tweaked so that they don't apply to Xephyr. (Removing those patches from the build results in an xorg-x11-server-Xephyr that works fine with clutter 1.2.) To reproduce: - Install gnome-shell packages from http://fedorapeople.org/~walters/gnome-shell-F12 - gnome-shell --xephyr You'll get an all-black xephyr window and some "could not create drawable" errors in the terminal. Alternatively: - build clutter 1.2 (eg, from pkgcvs, or using gnome-shell jhbuild, http://live.gnome.org/GnomeShell#Building. Just installing the rawhide packages won't work because they don't include the test programs) - Xephyr -ac :1 - try to run any program in clutter/tests/interactive/ under Xephyr
There is nothing to triage here. Switching to ASSIGNED so that developers have responsibility to do whatever they want to do with it.
That's... curious. I can't think of any reason why Xephyr wouldn't support GLX 1.4.
I guess it's possible that it does mostly support 1.4, but there is a bug in its implementation of some particular feature that clutter needs. The clutter code is in clutter/glx/clutter-backend-glx.c:clutter_backend_glx_create_context: backend_glx->dummy_xwin = XCreateWindow (...); /* Try and create a GLXWindow to use with extensions dependent on * GLX versions >= 1.3 that don't accept regular X Windows as GLX * drawables. */ if (glXQueryVersion (backend_x11->xdpy, &major, &minor) && major == 1 && minor >= 3) { backend_glx->dummy_glxwin = glXCreateWindow (backend_x11->xdpy, config, backend_glx->dummy_xwin, NULL); } The glXCreateWindow call prints the "failed to create drawable" error (glx_pbuffer.c:CreateDrawable) and ends up returning a non-NULL but non-functional GLXWindow.
Based on comparison with bug 578782 it seems to be a software-mesa issue rather than anything Xephyr specific - the same crash can be triggered for any clutter app with LIBGL_ALWAYS_SOFTWARE=1.
*** Bug 578782 has been marked as a duplicate of this bug. ***
Can someone try setting MALLOC_PERTURB_ to a non-zero value and trying this? On my machine, it brings the system down, since it tries to malloc width*height which are undefined values once it gets to this point, since XGetGeometry fails and doesn't set width and height in swrastGetDrawableInfo, I think? If no MALLOC_PERTURB_, then it just allocates a huge amount and never writes to it, so it's ok. $ gdb --args ./pong2 Reading symbols from /home/agoode/clutter-toys/pong/pong2...done. (gdb) r Starting program: /home/agoode/clutter-toys/pong/pong2 [Thread debugging using libthread_db enabled] failed to create drawable ^C Program received signal SIGINT, Interrupt. memset () at ../sysdeps/x86_64/memset.S:1057 1057 movntdq %xmm0,0x70(%rdi) Missing separate debuginfos, use: debuginfo-install expat-2.0.1-10.fc13.x86_64 libXau-1.0.5-1.fc12.x86_64 libXxf86vm-1.1.0-1.fc13.x86_64 libdrm-2.4.20-1.fc13.x86_64 libxcb-1.5-1.fc13.x86_64 pixman-0.18.0-1.fc13.x86_64 (gdb) bt #0 memset () at ../sysdeps/x86_64/memset.S:1057 #1 0x0000003715878ca2 in _int_malloc (av=<value optimized out>, bytes=<value optimized out>) at malloc.c:4749 #2 0x0000003715879b0d in __libc_malloc (bytes=1181017157) at malloc.c:3660 #3 0x00007ffff1d914f1 in _mesa_soft_renderbuffer_storage (ctx=0x63a1f0, rb= 0x970780, internalFormat=36168, width=55, height=<value optimized out>) at main/renderbuffer.c:1131 #4 0x00007ffff1d74e4f in _mesa_resize_framebuffer (ctx=0x63a1f0, fb=0x96c0b0, width=55, height=646195555) at main/framebuffer.c:302 #5 0x00007ffff1d50d05 in swrast_check_and_update_window_size (ctx=0x63a1f0, fb=0x96c0b0) at swrast.c:453 #6 0x00007ffff1d50d5d in driBindContext (ctx=0x63a1f0, draw=0x96c0b0, read= 0x96c0b0) at swrast.c:616 #7 0x0000003726824d69 in MakeContextCurrent (dpy=0x611d00, draw=94371844, read=94371844, gc=0x633fa0) at glxcurrent.c:402 #8 0x0000003732eaac99 in clutter_backend_glx_create_context (backend= 0x60f060 [ClutterBackendGLX], error=0x7fffffffd990) at clutter-backend-glx.c:589 #9 0x0000003732e5c553 in _clutter_feature_init (error=0x7fffffffd990) at ./clutter-feature.c:106 #10 0x0000003732e667db in clutter_init_real (error=0x7fffffffd990) at ./clutter-main.c:1537 #11 0x000000371704aee8 in IA__g_option_context_parse (context=0x60ec20, argc=<value optimized out>, argv=<value optimized out>, error=<value optimized out>) at goption.c:1957 #12 0x0000003732e66ab1 in clutter_parse_args (argc=0x7fffffffd9dc, argv= 0x7fffffffd9d0) at ./clutter-main.c:1959 #13 clutter_init (argc=0x7fffffffd9dc, argv=0x7fffffffd9d0) at ./clutter-main.c:2012 #14 0x0000000000402cf0 in main (argc=1, argv=0x7fffffffdc68) at pong2.c:345
(In reply to comment #6) > Can someone try setting MALLOC_PERTURB_ to a non-zero value and trying this? On > my machine, it brings the system down, since it tries to malloc width*height > which are undefined values once it gets to this point, since XGetGeometry fails > and doesn't set width and height in swrastGetDrawableInfo, I think? If no > MALLOC_PERTURB_, then it just allocates a huge amount and never writes to it, > so it's ok. Once it says "failed to create drawable" it's already buggy, and the fact that it crashes after that is not interesting.
Ok, except that it sends the system into swap and never returns. This happens with empathy, for example, or anything that uses clutter. I would be happy if it merely crashed.
hi, Is this related to https://bugzilla.redhat.com/show_bug.cgi?id=591771 ? Ankur
no
This still seems to be an issue with F13, any fix out there?
Note that this will happen to all users that have installed Fedora with the "video safe" option, because their kernels will be booting with nomodeset.
I think I'm hitting this bug in f14. At least I was getting the "failed to create drawable" while trying to run the clutter toy apps. The specific cause of the problem is a check in src/glx/drisw_glx.c:driCreateDrawable(). It turns out that just commenting out the check fixed the problem for me. The toy apps work fine with the following patch applied. HTH. --- mesa-20101207/src/glx/drisw_glx.c 2010-12-06 19:59:20.000000000 -0500 +++ mesa-20101207.new/src/glx/drisw_glx.c 2010-12-18 02:03:41.612825351 -0500 @@ -362,8 +362,8 @@ const __DRIswrastExtension *swrast = psc->swrast; /* Old dri can't handle GLX 1.3+ drawable constructors. */ - if (xDrawable != drawable) - return NULL; +// if (xDrawable != drawable) +// return NULL; pdp = Xmalloc(sizeof(*pdp)); if (!pdp)
Fixed in F16 (and I think F15 too). F14 is EOL, please update if this issue still affects you.