TBB Sandbox crashed after finishing bootstrap

TBB Sandbox crashed after finishing bootstrap (it happened twice and now it works fine), it left this error

2017/05/16 08:17:39 firefox: [3] ###!!! ABORT: Request 130.3: BadShmSeg; 3 requests ago: file /home/debian/build/tor-browser/toolkit/xre/nsX11ErrorHandler.cpp, line 157
2017/05/16 08:17:39 firefox: [3] ###!!! ABORT: Request 130.3: BadShmSeg; 3 requests ago: file /home/debian/build/tor-browser/toolkit/xre/nsX11ErrorHandler.cpp, line 157
2017/05/16 08:17:40 tor: May 16 07:17:40.000 [notice] Catching signal TERM, exiting cleanly.

Trac:
Username: leakedwiki

added component::archived/tor browser sandbox owner::yawning priority::medium reporter::leakedwiki resolution::fixed severity::normal status::closed type::defect labels

Update: Crash happens about half the time I launch the sandbox. (system: Ubuntu 17.04)

Trac:
Username: leakedwiki

Unless there's other parts of Firefox that also puke when MIT-SHM isn't available, I assume this is the libcairo bug described in https://bugzilla.mozilla.org/show_bug.cgi?id=1271100#c20

There's mitigations/workarounds for this (that are also applied in newer firefox), by hooking XQueryExtension and XShmQueryExtension. If your libcario2 is at version 1.14.8, then I suggest bringing it up with the Firefox developers.

There likely isn't anything more I can do with this, since I don't have a system that can reproduce this anymore (the mitigations I applied were sufficient to squash it when I saw it, and it's a race condition so it's hard to reproduce reliably to begin with), and it's either a firefox or library bug.

Trac:
Resolution: N/A to wontfix
Status: new to closed

leakedwiki: what version of libcairo comes with your ubuntu 17.04?

Replying to arma:

leakedwiki: what version of libcairo comes with your ubuntu 17.04?

libcairo2 is already the newest version (1.14.8-1).

@yawning ok, i will try with tbb 7.0a3 to see if it's fixed for ff52esr

Edit: So far looks good!

Trac:
Username: leakedwiki

It's a race condition so behavior will be non-deterministic.

After thinking about this for a bit, I probably should also include code that hooks libxcb's extension query calls, assuming they're getting called. Alternatively I could allow MIT-SHM to work, but that to me is "punching holes in the sandbox to work around other people's mistakes", so I'd rather not.

Trac:
Status: closed to reopened
Resolution: wontfix to N/A

Replying to yawning:

After thinking about this for a bit, I probably should also include code that hooks libxcb's extension query calls, assuming they're getting called.

They are, but it doesn't appear to be the culprit here, the only XCB extension queries I see are something checking if the BIG-REQUESTS extension is supported. Oh well, I don't have a Ubuntu VM anymore, so there isn't an easy way to check if the behavior is any different.

So yeah. Installed ewwbuntu in a VM, and it crashes on startup intermittently. Adding debugging instrumentation makes it crash less (race conditions are dumb). It's not calling the xcb extension query routines at all from what I can tell, and it is calling my versions of the xlib ones. So I have no idea why firefox (or one of it's dependencies) thinks it's ok to use MIT-SHM, when the X server doesn't appear to support it.

I can't tell if anything I've tried to get it to not crash actually fixes the problem because behavior is intermitent. If someone that's not me[0] gets a usable stack trace from when it aborts, then forward progress can happen here, otherwise I think this will languish in the bug tracker forever.

• Forcing layers.offmainthreadcomposition.enabled to false may help.
• Rejecting more extensions (DRI, GLX, SGI-GLX) may help.

[0]: One upon a time I had a branch of the sandbox code that let me run gdb/get stack traces, but that's long since rotted, and it was a huge mess, that I'm not willing to clean up.

Trac:
Status: reopened to needs_information

I'm going to call this fixed due to the changes from #22648 (closed) and #20776 (closed). At the X protocol level, the X server visible to firefox no longer supports MIT-SHM, and will always reject QueryExtension requests to check it's presence.

If this or similar asserts happen with master, it's due to horrifically broken library or application code, that's attempting to use unsupported extensions in violation of the X11 protocol, and thus is not my problem.

Trac:
Status: needs_information to closed
Resolution: N/A to fixed

closed