I'm seeing this on Ubuntu 15.10. STR: 1. SSH into a Linux box. 2. Run vnc4server. 3. export a DISPLAY environment variable as per the output of step 2. 4. Attach to the remote VNC server locally. 5. Run ./mach run. Firefox crashes at startup with: [Parent 17319] ###!!! ABORT: X_ShmPutImage: BadAccess (attempt to access private resource denied); sync; id=0x0: file /home/ehsan/moz/src3/toolkit/xre/nsX11ErrorHandler.[345/27704] 47 Hit MOZ_CRASH() at /home/ehsan/moz/src3/memory/mozalloc/mozalloc_abort.cpp:33 Program /home/ehsan/moz/src3/obj-ff-dbg/dist/bin/firefox (pid = 17319) received signal 11. Stack: #01: ???[/home/ehsan/moz/src3/obj-ff-dbg/dist/bin/libxul.so +0x6d92102] #02: ???[/home/ehsan/moz/src3/obj-ff-dbg/dist/bin/libxul.so +0x70fd87d] #03: ???[/lib/x86_64-linux-gnu/libpthread.so.0 +0x10d10] #04: mozalloc_abort(char const*)[/home/ehsan/moz/src3/obj-ff-dbg/dist/bin/firefox +0x6f04] #05: ???[/home/ehsan/moz/src3/obj-ff-dbg/dist/bin/libxul.so +0xcb9a17] #06: NS_DebugBreak[/home/ehsan/moz/src3/obj-ff-dbg/dist/bin/libxul.so +0xcb9922] #07: ???[/home/ehsan/moz/src3/obj-ff-dbg/dist/bin/libxul.so +0x5697900] #08: ???[/home/ehsan/moz/src3/obj-ff-dbg/dist/bin/libxul.so +0x5691cac] #09: g_logv[/lib/x86_64-linux-gnu/libglib-2.0.so.0 +0x507e4] #10: g_log[/lib/x86_64-linux-gnu/libglib-2.0.so.0 +0x50a0f] #11: ???[/usr/lib/x86_64-linux-gnu/libgdk-3.so.0 +0x52828] #12: ???[/usr/lib/x86_64-linux-gnu/libgdk-3.so.0 +0x5d879] #13: _XError[/usr/lib/x86_64-linux-gnu/libX11.so.6 +0x3fc4d] #14: ???[/usr/lib/x86_64-linux-gnu/libX11.so.6 +0x3cad7] #15: ???[/usr/lib/x86_64-linux-gnu/libX11.so.6 +0x3cb95] #16: _XReply[/usr/lib/x86_64-linux-gnu/libX11.so.6 +0x3db50] #17: XGetAtomName[/usr/lib/x86_64-linux-gnu/libX11.so.6 +0x21707] #18: gdk_x11_xatom_to_atom_for_display[/usr/lib/x86_64-linux-gnu/libgdk-3.so.0 +0x5e1e7] #19: ???[/usr/lib/x86_64-linux-gnu/libgdk-3.so.0 +0x53644] #20: ???[/usr/lib/x86_64-linux-gnu/libgdk-3.so.0 +0x58c12] #21: ???[/usr/lib/x86_64-linux-gnu/libgdk-3.so.0 +0x5875c] #22: gdk_display_get_event[/usr/lib/x86_64-linux-gnu/libgdk-3.so.0 +0x2b629] #23: ???[/usr/lib/x86_64-linux-gnu/libgdk-3.so.0 +0x58312] #24: g_main_context_dispatch[/lib/x86_64-linux-gnu/libglib-2.0.so.0 +0x49ff7] #25: ???[/lib/x86_64-linux-gnu/libglib-2.0.so.0 +0x4a250] [Child 17402] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file /home/ehsan/moz/src3/toolkit/xre/nsXREDirProvider.cpp, line 1703 #26: g_main_context_iteration[/lib/x86_64-linux-gnu/libglib-2.0.so.0 +0x4a2fc] #27: ???[/home/ehsan/moz/src3/obj-ff-dbg/dist/bin/libxul.so +0x45f392d] #28: ???[/home/ehsan/moz/src3/obj-ff-dbg/dist/bin/libxul.so +0x45a5a67] #29: ???[/home/ehsan/moz/src3/obj-ff-dbg/dist/bin/libxul.so +0x45a5e51] #30: ???[/home/ehsan/moz/src3/obj-ff-dbg/dist/bin/libxul.so +0xd8d1e0] #31: ???[/home/ehsan/moz/src3/obj-ff-dbg/dist/bin/libxul.so +0xdf9ccb] #32: ???[/home/ehsan/moz/src3/obj-ff-dbg/dist/bin/libxul.so +0x1562c33] #33: ???[/home/ehsan/moz/src3/obj-ff-dbg/dist/bin/libxul.so +0x14d0e43] #34: ???[/home/ehsan/moz/src3/obj-ff-dbg/dist/bin/libxul.so +0x14d0dd8] #35: ???[/home/ehsan/moz/src3/obj-ff-dbg/dist/bin/libxul.so +0x14d0db1] #36: ???[/home/ehsan/moz/src3/obj-ff-dbg/dist/bin/libxul.so +0x45a5aea] #37: ???[/home/ehsan/moz/src3/obj-ff-dbg/dist/bin/libxul.so +0x55ad1d3] #38: ???[/home/ehsan/moz/src3/obj-ff-dbg/dist/bin/libxul.so +0x5689f73] #39: ???[/home/ehsan/moz/src3/obj-ff-dbg/dist/bin/libxul.so +0x568a517] #40: XRE_main[/home/ehsan/moz/src3/obj-ff-dbg/dist/bin/libxul.so +0x568a7e7] #41: ???[/home/ehsan/moz/src3/obj-ff-dbg/dist/bin/firefox +0x58f1] #42: ???[/home/ehsan/moz/src3/obj-ff-dbg/dist/bin/firefox +0x5c58] #43: __libc_start_main[/lib/x86_64-linux-gnu/libc.so.6 +0x20ac0] #44: _start[/home/ehsan/moz/src3/obj-ff-dbg/dist/bin/firefox +0x5019] #45: ??? (???:???) Setting gShmAvailable to false and rebuilding works around this issue. Running the MoCo built Nightly in this configuration gives: $ ~/Desktop/firefox/firefox -profile /tmp/xxx 1480467880687 addons.xpi-utils WARN Disabling foreign installed add-on ubufox@ubuntu.com in app-system-share ATTENTION: default value of option force_s3tc_enable overridden by environment. libGL error: No matching fbConfigs or visuals found libGL error: failed to load driver: swrast [Parent 18973] ###!!! ABORT: X_ShmPutImage: BadAccess (attempt to access private resource denied); 3 requests ago: file /builds/slave/m-cen-l64-ntly-000000000000000/build/src/toolkit/xre/nsX11ErrorHandler.cpp, line 147 [Parent 18973] ###!!! ABORT: X_ShmPutImage: BadAccess (attempt to access private resource denied); 3 requests ago: file /builds/slave/m-cen-l64-ntly-000000000000000/build/src/toolkit/xre/nsX11ErrorHandler.cpp, line 147 ExceptionHandler::GenerateDump cloned child 19092 ExceptionHandler::SendContinueSignalToChild sent continue signal to child ExceptionHandler::WaitForContinueSignal waiting for continue signal... ehsan@teenuxx:~/moz/src3$ [Child 19066] ###!!! ABORT: Aborting on channel error.: file /builds/slave/m-cen-l64-ntly-000000000000000/build/src/ipc/glue/MessageChannel.cpp, line 2155 [Child 19066] ###!!! ABORT: Aborting on channel error.: file /builds/slave/m-cen-l64-ntly-000000000000000/build/src/ipc/glue/MessageChannel.cpp, line 2155 Failed to open curl lib from binary, use libcurl.so instead For some strange reason when I run the MoCo bult Nightly in this configuration with my main profile, I don't get the crash. I suspected maybe I have a pref set, but nuking my prefs.js didn't seem to change anything.

Is this a dup of bug 1271100?

No, it happens with the patch from that bug applied too.

Is this still around?

Yes.

This is the backtrace I get under gdb: #0 0x00007ff0fd114e7d in nanosleep () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007ff0fd114d14 in __sleep (seconds=0) at ../sysdeps/unix/sysv/linux/sleep.c:138 #2 0x00007ff0ee8e7577 in ah_crap_handler(int) (signum=11) at /home/ehsan/moz/src/toolkit/xre/nsSigHandlers.cpp:103 #3 0x00007ff0ee8c445a in nsProfileLock::FatalSignalHandler(int, siginfo_t*, void*) (signo=11, info=0x7ffe17b89130, context=0x7ffe17b89000) at /home/ehsan/moz/src/toolkit/profile/nsProfileLock.cpp:191 #4 0x00007ff0f0238540 in js::UnixExceptionHandler(int, siginfo_t*, void*) (signum=11, info=0x7ffe17b89130, context=0x7ffe17b89000) at /home/ehsan/moz/src/js/src/ds/MemoryProtectionExceptionHandler.cpp:263 #5 0x00007ff0f0609559 in WasmFaultHandler<(Signal)0>(int, siginfo_t*, void*) (signum=11, info=0x7ffe17b89130, context=0x7ffe17b89000) at /home/ehsan/moz/src/js/src/wasm/WasmSignalHandlers.cpp:1211 #6 0x00007ff0fdec9d10 in <signal handler called> () at /lib/x86_64-linux-gnu/libpthread.so.0 #7 0x0000000000406e9b in mozalloc_abort(char const*) (msg=0x7ffe17b89840 "[Parent 32576] ###!!! ABORT: X_ShmPutImage: BadAccess (attempt to access private resource denied); 3 requests ago; id=0x0\nRe-running with MOZ_X_SYNC=1 in the environment may give a more helpful backtr"...) at /home/ehsan/moz/src/memory/mozalloc/mozalloc_abort.cpp:33 #8 0x00007ff0e9c80ee7 in Abort(char const*) (aMsg=0x7ffe17b89840 "[Parent 32576] ###!!! ABORT: X_ShmPutImage: BadAccess (attempt to access private resource denied); 3 requests ago; id=0x0\nRe-running with MOZ_X_SYNC=1 in the environment may give a more helpful backtr"...) at /home/ehsan/moz/src/xpcom/base/nsDebugImpl.cpp:449 #9 0x00007ff0e9c80df2 in NS_DebugBreak(uint32_t, char const*, char const*, char const*, int32_t) (aSeverity=3, aStr=0x7ff0c4207608 "X_ShmPutImage: BadAccess (attempt to access private resource denied); 3 requests ago; id=0x0\nRe-running with MOZ_X_SYNC=1 in the environment may give a more helpful backtrace.", aExpr=0x0, aFile=0x7ff0f15e4c40 "/home/ehsan/moz/src/toolkit/xre/nsX11ErrorHandler.cpp", aLine=147) at /home/ehsan/moz/src/xpcom/base/nsDebugImpl.cpp:405 #10 0x00007ff0ee8eb68f in X11Error(Display*, XErrorEvent*) (display=0x7ff0e6f17000, event=0x7ffe17b8a400) at /home/ehsan/moz/src/toolkit/xre/nsX11ErrorHandler.cpp:147 #11 0x00007ff0ee8e57ef in GdkErrorHandler(gchar const*, GLogLevelFlags, gchar const*, gpointer) (log_domain=0x7ff0fbdbe40e "Gdk", log_level=6, message=0x7ff0c6d6ac00 "The program 'firefox' received an X Window System error.\nThis probably reflects a bug in the program.\nThe error was 'BadAccess (attempt to access private resource denied)'.\n (Details: serial 276 erro"..., user_data=0x0) at /home/ehsan/moz/src/toolkit/xre/nsGDKErrorHandler.cpp:83 #12 0x00007ff0f94277e4 in g_logv () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #13 0x00007ff0f9427a0f in g_log () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #14 0x00007ff0fbd87828 in () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 #15 0x00007ff0fbd92879 in () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 #16 0x00007ff0fb629c4d in _XError () at /usr/lib/x86_64-linux-gnu/libX11.so.6 #17 0x00007ff0fb626ad7 in () at /usr/lib/x86_64-linux-gnu/libX11.so.6 #18 0x00007ff0fb626b95 in () at /usr/lib/x86_64-linux-gnu/libX11.so.6 #19 0x00007ff0fb627b50 in _XReply () at /usr/lib/x86_64-linux-gnu/libX11.so.6 #20 0x00007ff0fb624c89 in XTranslateCoordinates () at /usr/lib/x86_64-linux-gnu/libX11.so.6 #21 0x00007ff0fbd893a5 in () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 #22 0x00007ff0fbd8dc12 in () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 #23 0x00007ff0fbd8d75c in () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 #24 0x00007ff0fbd60629 in gdk_display_get_event () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 #25 0x00007ff0fbd8d312 in () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 #26 0x00007ff0f9420ff7 in g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #27 0x00007ff0f9421250 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #28 0x00007ff0f94212fc in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #29 0x00007ff0ed71efcd in nsAppShell::ProcessNextNativeEvent(bool) (this=0x7ff0d717b430, mayWait=false) at /home/ehsan/moz/src/widget/gtk/nsAppShell.cpp:270 #30 0x00007ff0ed6cd0e3 in nsBaseAppShell::DoProcessNextNativeEvent(bool) (this=0x7ff0d717b430, mayWait=false) at /home/ehsan/moz/src/widget/nsBaseAppShell.cpp:138 #31 0x00007ff0ed6cd4cd in nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal*, bool) (this=0x7ff0d717b430, thr=0x7ff0e6f04300, mayWait=false) at /home/ehsan/moz/src/widget/nsBaseAppShell.cpp:277 #32 0x00007ff0e9d5bdbd in nsThread::ProcessNextEvent(bool, bool*) (this=0x7ff0e6f04300, aMayWait=false, aResult=0x7ffe17b8ae07) at /home/ehsan/moz/src/xpcom/threads/nsThread.cpp:1213 #33 0x00007ff0e9dcf70b in NS_ProcessNextEvent(nsIThread*, bool) (aThread=0x7ff0e6f04300, aMayWait=false) at /home/ehsan/moz/src/xpcom/glue/nsThreadUtils.cpp:390 #34 0x00007ff0ea57c278 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (this=0x7ff0e6f5bb40, aDelegate=0x7ff0fceaf690) at /home/ehsan/moz/src/ipc/glue/MessagePump.cpp:96 #35 0x00007ff0ea4e16e0 in MessageLoop::RunInternal() (this=0x7ff0fceaf690) at /home/ehsan/moz/src/ipc/chromium/src/base/message_loop.cc:238 #36 0x00007ff0ea4e1664 in MessageLoop::RunHandler() (this=0x7ff0fceaf690) at /home/ehsan/moz/src/ipc/chromium/src/base/message_loop.cc:231 #37 0x00007ff0ea4e1628 in MessageLoop::Run() (this=0x7ff0fceaf690) at /home/ehsan/moz/src/ipc/chromium/src/base/message_loop.cc:211 #38 0x00007ff0ed6cd166 in nsBaseAppShell::Run() (this=0x7ff0d717b430) at /home/ehsan/moz/src/widget/nsBaseAppShell.cpp:156 #39 0x00007ff0ee7d7d73 in nsAppStartup::Run() (this=0x7ff0d7118420) at /home/ehsan/moz/src/toolkit/components/startup/nsAppStartup.cpp:283 #40 0x00007ff0ee8db230 in XREMain::XRE_mainRun() (this=0x7ffe17b8b250) at /home/ehsan/moz/src/toolkit/xre/nsAppRunner.cpp:4461 #41 0x00007ff0ee8dbcef in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) (this=0x7ffe17b8b250, argc=4, argv=0x7ffe17b8c5d8, aConfig=...) at /home/ehsan/moz/src/toolkit/xre/nsAppRunner.cpp:4638 #42 0x00007ff0ee8dbff4 in XRE_main(int, char**, mozilla::BootstrapConfig const&) (argc=4, argv=0x7ffe17b8c5d8, aConfig=...) at /home/ehsan/moz/src/toolkit/xre/nsAppRunner.cpp:4729 #43 0x00007ff0ee8f106e in mozilla::BootstrapImpl::XRE_main(int, char**, mozilla::BootstrapConfig const&) (this=0x7ff0fceb50a8, argc=4, argv=0x7ffe17b8c5d8, aConfig=...) at /home/ehsan/moz/src/toolkit/xre/Bootstrap.cpp:45 #44 0x00000000004058fd in do_main(int, char**, char**) (argc=4, argv=0x7ffe17b8c5d8, envp=0x7ffe17b8c600) at /home/ehsan/moz/src/browser/app/nsBrowserApp.cpp:241 #45 0x0000000000405c5e in main(int, char**, char**) (argc=4, argv=0x7ffe17b8c5d8, envp=0x7ffe17b8c600) at /home/ehsan/moz/src/browser/app/nsBrowserApp.cpp:347

Karl, anything that jumps out at you here?

Speaking to Lee today on IRC about this, he gave me this experimental patch which bypasses the crash and allows us to paint the Firefox window.

Comment on attachment 8829654 [details] [diff] [review] check first xcb_shm_put_image request in case xcb_shm_attach does not properly validate the shm segment I can through the X server source code and in theory xcb_shm_attach should do all validation up front that guarantees BadAccess never occurs on an xcb_shm_put_image call. It should be impossible for xcb_shm_put_image to return BadAccess. But for whatever reason, on Ehsan's setup, it is not behaving this way. I wonder if Ubuntu has patched it somehow. In any case, this patch just tries to do a checked request initially to verify that XShmPutImage works.

Comment on attachment 8829654 [details] [diff] [review] check first xcb_shm_put_image request in case xcb_shm_attach does not properly validate the shm segment I'm not very comfortable taking a patch just because it works, and, as you say, we don't expect it to help, so there is something we are missing in our understanding. Given we don't know why the Put is failing the first time, we don't know whether it would always be the first time, and, yes, we don't want to check every time. vnc4server is a fairly niche application. I don't think it is necessary to rush a workaround for this. The code is open source and so the real cause of the failure can be found if necessary. If it is a bug in vnc4server, then perhaps we can detect old X servers, but the appropriate solution will be much clearer when the cause of the problem is known. GTK2 uses XShm but doesn't protect from errors in XShmPutImage AFAICS, so it seems there is something that Gecko is doing differently.

vnc4server is based on a very old version of the X server code. The implementation hasn't changed a whole lot. The size check on ShmPutImage has changed, and that can lead to BadAccess in vnc4server, but it is not obvious to me that this would be the problem. The rest looks similar though. Ehsan, can you confirm my understanding that vnc4server and mach are running on the same machine? If that is the situation, then I don't know a good reason why the ShmPutImage should fail. Can you install xtrace from [1] or [2] please and run as xtrace strace -e trace=ipc -f obj/dist/bin/firefox >& /tmp/shm.trace (Don't run xtrace from glibc.) Then look for "MIT-SHM-Request" and associated shm syscalls in the output file. [1] https://xtrace.alioth.debian.org/ [2] http://packages.ubuntu.com/xenial/x11/xtrace

(In reply to Karl Tomlinson (:karlt) from comment #10) > Ehsan, can you confirm my understanding that vnc4server and mach are running > on the same machine? That's correct. My workflow is like this: * ssh to my linux box. * vnc4server * ./mach build * ./mach run * attach a VNC client to see the browser window > If that is the situation, then I don't know a good reason why the ShmPutImage > should fail. > > Can you install xtrace from [1] or [2] please and run as > > xtrace strace -e trace=ipc -f obj/dist/bin/firefox >& /tmp/shm.trace Here is the full log.

Comment on attachment 8834198 [details] shm.trace Thanks! > [...] {depth=16 bits/pixel=16 scanline-pad=32}; [...] The removal of XShmCreateImage() code is assuming a scanline-pad of 16 for the image format, but scanline-pad is 32, changing bytes_per_line when depth is 16 and width is odd. It should be fine to keep the XShmCreateImage() usage because it doesn't rely on XShmQueryExtension(), or instead _XGetScanlinePad() can be used to calculate bytes_per-line and so avoid creating the XImage. https://hg.mozilla.org/mozilla-central/rev/803d0028289a#l1.70 https://hg.mozilla.org/mozilla-central/rev/803d0028289a#l1.332

(In reply to Karl Tomlinson (:karlt) from comment #12) > Comment on attachment 8834198 [details] > shm.trace > > Thanks! > > > [...] {depth=16 bits/pixel=16 scanline-pad=32}; [...] > > The removal of XShmCreateImage() code is assuming a scanline-pad of 16 for > the > image format, but scanline-pad is 32, changing bytes_per_line when depth is > 16 > and width is odd. > > It should be fine to keep the XShmCreateImage() usage because it doesn't rely > on XShmQueryExtension(), or instead _XGetScanlinePad() can be used to > calculate bytes_per-line and so avoid creating the XImage. > > https://hg.mozilla.org/mozilla-central/rev/803d0028289a#l1.70 > https://hg.mozilla.org/mozilla-central/rev/803d0028289a#l1.332 Are you saying this is the cause of the bug Ehsan is experiencing, or is this just an incidental finding? Please clarify.

Ehsan, can you check if this patch fixes your issue?

(In reply to Lee Salzman [:lsalzman] from comment #14) > Created attachment 8838390 [details] [diff] [review] > make nsShmImage stride compatible with XShm > > Ehsan, can you check if this patch fixes your issue? Yes, it does!

Comment on attachment 8838390 [details] [diff] [review] make nsShmImage stride compatible with XShm >+ int bitsPerLine = ((bitsPerPixel * aSize.width + scanlinePad - 1) / scanlinePad) * scanlinePad; Wrap to keep within 80 columns.

Pushed by lsalzman@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/6c29f41213fe make nsShmImage stride compatible with XShm. r=karlt

Did we want to consider backporting this to Aurora/Beta?

Comment on attachment 8838390 [details] [diff] [review] make nsShmImage stride compatible with XShm Approval Request Comment [Feature/Bug causing the regression]: bug 1286649, so affects 50+ [User impact if declined]: We incorrectly create shared memory for some pixel formats on X11, which can cause crashes on some X servers soon after startup. [Is this code covered by automated tests?]: yes [Has the fix been verified in Nightly?]: yes [Needs manual test from QE? If yes, steps to reproduce]: no [List of other uplifts needed for the feature/fix]: 52, 53 [Is the change risky?]: no [Why is the change risky/not risky?]: Instead of incorrectly guessing at the stride of shared memory images ourselves, we now exactly match how Xlib was calculating it. [String changes made/needed]: None

Comment on attachment 8838390 [details] [diff] [review] make nsShmImage stride compatible with XShm Fix a startup crash when launching Firefox with a VNC display. Aurora53+.

Comment on attachment 8838390 [details] [diff] [review] make nsShmImage stride compatible with XShm fix an x11 error with xshm, beta52+ Seems like a good thing to have in esr52.

Setting qe-verify- based on Lee's assessment on manual testing needs (see Comment 20) and the fact that this fix has automated coverage.