X (gtk2 using?) ports crash OS X 10.5.8 X11.bin

[eischen@…]

Thunar, firefox-11, transmission-x11 all crash immediately after starting. Both firefox and Thunar worked before updating macports (from 1.9.1 to 2.0.3). After updating macports (selfupdate) I upgraded all installed ports. Now the above do not work and crash. Are there any work-arounds for this?

[eischen@…]

Console output and crash info from Apple problem report

[ryandesign (Ryan Carsten Schmidt)]

Are you using the X11 server that comes with Mac OS X (/Applications/Utilities/X11.app) or the one in the MacPorts xorg-server port (/Applications/MacPorts/X11.app)? Whichever one you're using, try the other one.

[eischen@…]

Replying to ryandesign@…:

Are you using the X11 server that comes with Mac OS X (/Applications/Utilities/X11.app) or the one in the MacPorts xorg-server port (/Applications/MacPorts/X11.app)? Whichever one you're using, try the other one.

Ok, I was using the MAC OS X server, and have just tried using the MacPorts server. The MacPorts server does not crash, but Thunar, firefox, transmission all error off with:

$ firefox-x11
Xlib:  extension "RANDR" missing on display "/tmp/launch-HkCMGV/:0".
dyld: lazy symbol binding failed: Symbol not found: _cairo_xlib_surface_create
  Referenced from: /opt/local/lib/libgdk-x11-2.0.0.dylib
  Expected in: /opt/local/lib/libcairo.2.dylib

dyld: Symbol not found: _cairo_xlib_surface_create
  Referenced from: /opt/local/lib/libgdk-x11-2.0.0.dylib
  Expected in: /opt/local/lib/libcairo.2.dylib

Trace/BPT trap

What's missing? port variant cairo shows the following:

$ port variant cairo
cairo has the variants:
   no_x11: Legacy compatibility variant
     * conflicts with opengl x11 x11_xcb
   opengl: Add OpenGL graphics interface
     * conflicts with no_x11
     * requires x11
   quartz: Support for native Mac OS X graphics
   universal: Build for multiple architectures
[+]x11: Enable X11 support
     * conflicts with no_x11
   x11_xcb: Legacy compatibility variant
     * conflicts with no_x11
     * requires x11

[eischen@…]

I reinstalled cairo with:

$ sudo port upgrade --enforce-variants cairo +x11 +quartz +opengl

and everything seems to work now.

[su-v]

Cc Me!

[su-v]

Also affects bundled applications like e.g. provided by Inkscape for users who don't want to install inkscape via MacPorts: even though the application was build on Leopard, using the dependencies from an up-to-date MacPorts tree at the time of the release, it can't be run on a vanilla Mac OS X Leopard system any more: Inkscape.app (0.48.2) crashes Apple's X11 2.1.6 with the same backtrace as was attached from Thunar. Since application bundles like provided by Inkscape.org don't use an installer, they can't (and don't want to) include a newer version of X11/Xquartz.

Related bug report for Inkscape:
Bug 878368 in Inkscape: “​Trying to open inkscape version 0.48.2 it crash the x11 on my Mac OS X ver. 10.5.8 . ”

AFAICT from my local builds on Leopard, the crashes of Apple's X11 2.1.6 started when cairo was rebuilt after r78840 ("always enable xcb when x11 is enabled"), which might be confirmed by the fact that the crashes no longer occur after upgrading (overwriting) X11 with the earliest Xquartz release built with xcb support (​2.5.1).

[jmroot (Joshua Root)]

Assigning based on comment:3.

[ryandesign (Ryan Carsten Schmidt)]

comment:3 says the problem was solved by rebuilding cairo. The version of cairo has been increased more than once since then, thus everybody affected by the issue should already have rebuilt the port.

[su-v]

Replying to ryandesign@…:

comment:3 says the problem was solved by rebuilding cairo. The version of cairo has been increased more than once since then, thus everybody affected by the issue should already have rebuilt the port.

Because the user confirmed to first have switched the X server:

Ok, I was using the MAC OS X server, and have just tried using the MacPorts server. The MacPorts server does not crash, but (…)

GTK+-based applications linked to cairo built via MacPorts [1] will still crash Apple's X11 2.1.6 on Leopard (I don't know about the situation on Snow Leopard).

[1] (which enforced enabling xcb with the default variant at a time it was still considered unstable and experimental by the cairo devs - IIRC because one application (awesome WM) requires it)

[ryandesign (Ryan Carsten Schmidt)]

Ok if this is still a bug in cairo then someone (ideally someone experiencing the problem, who can test potential fixes) should report it to the developers of cairo.

[su-v]

Replying to ryandesign@…:

Ok if this is still a bug in cairo then someone (ideally someone experiencing the problem, who can test potential fixes) should report it to the developers of cairo.

It is not a bug in cairo: the configure options of the default install of cairo in MacPorts enable features which are not compatible with the vanilla X11 server provided by Apple on Leopard.

A possible option would be to not enable xcb-related features of cairo on older versions of Mac OS X, and instead offer them as variant again to allow users to enable/disable them if needed without adding a local repository to edit / maintain additional variants of the cairo port.

The output of configure for the port 'cairo' still has this notice, btw:

--- The Xlib/XCB functions feature is still under active development and is
--- included in this release only as a preview. It does NOT fully work yet
--- and incompatible changes may yet be made to Xlib/XCB functions specific
--- API.

[ryandesign (Ryan Carsten Schmidt)]

Replying to suv-sf@…:

It is not a bug in cairo: the configure options of the default install of cairo in MacPorts enable features which are not compatible with the vanilla X11 server provided by Apple on Leopard.

I see. Well Joshua made that change in r78840 for #23483 (another port required the cairo's xcb support). Any suggestions?

[jmroot (Joshua Root)]

AFAIK, the client libs should be asking the server what features it supports and only using the ones it reports. Just because xcb support is enabled in cairo shouldn't mean you have to use it. (And of course, the server shouldn't crash no matter what kind of invalid/unrecognised input it's given, but that's not something we can affect except by installing our own.)

Any insights, Jeremy?

[jeremyhu (Jeremy Huddleston Sequoia)]

xcb is a protocol binding library. xcb is not a server feature. It's just a way to talk to the server. Think of it as an alternative to Xlib.

It looks like the cairo API changed, just like they warned it could.

Just revbump gtk to force a rebuild, and you should be fine.

[jmroot (Joshua Root)]

Replying to jeremyhu@…:

xcb is a protocol binding library. xcb is not a server feature. It's just a way to talk to the server. Think of it as an alternative to Xlib.

That's what I thought. So how is it crashing the server?

I agree the missing symbols are probably fixed by stuff having been rebuilt, but that wasn't the original problem.

[jeremyhu (Jeremy Huddleston Sequoia)]

Ah, well sorry. I didn't look at the crash report. I assumed the snippits in comments were from it. The crash report shows:

Thread 2 Crashed:
67	0   X11.bin                             0x00025f38 RootlessGlyphs + 84
68	1   X11.bin                             0x0011e021 CompositeGlyphs + 163
69	2   X11.bin                             0x00121b60 ProcRenderCompositeGlyphs + 1526
70	3   X11.bin                             0x001236e8 ProcRenderDispatch + 60
71	4   X11.bin                             0x000ec41a XaceCatchExtProc + 173
72	5   X11.bin                             0x0007dad1 Dispatch + 691
73	6   X11.bin                             0x0009b497 dix_main + 1818
74	7   X11.bin                             0x00019526 server_thread + 62
75	8   libSystem.B.dylib                   0x90720055 _pthread_start + 321
76	9   libSystem.B.dylib                   0x9071ff12 thread_start + 34

That is probably the bug mentioned in the release notes for XQuartz 2.6.2: ​http://xquartz.macosforge.org/trac/wiki/X112.6.2

Please install XQuartz 2.6.3 on Leopard or use the X11 server from MacPorts.

Leaving reopen to possibly revbump gtk if needed.

[jmroot (Joshua Root)]

There have already been several gtk2 updates since this was opened.