1045752 - B2G Desktop on Linux 64-bit crashes constantly due to X11 error

Status: RESOLVED FIXED

(Firefox OS Graveyard :: General, defect)

Description

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

Assertion failure: NS_IsMainThread(), at /share/mozbuild/gecko-dev/gfx/src/X11Util.cpp:62

Don't have a good stack yet.

Comment 1

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

ni?'ing karlt since this appears due to bug 1043772.

Stack (from thread 29, so definitely not main thread :) ):
#0  0x00007f276227d8bd in nanosleep () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f276227d754 in __sleep (seconds=0) at ../sysdeps/unix/sysv/linux/sleep.c:137
#2  0x00007f275fa50042 in ah_crap_handler (signum=11) at /share/mozbuild/gecko-dev/toolkit/xre/nsSigHandlers.cpp:88
#3  0x00007f275fa441cb in nsProfileLock::FatalSignalHandler (signo=11, info=0x7f2743efdfb0, context=0x7f2743efde80) at /share/mozbuild/gecko-dev/profile/dirserviceprovider/src/nsProfileLock.cpp:185
#4  0x00007f275fffe847 in AsmJSFaultHandler (signum=11, info=0x7f2743efdfb0, context=0x7f2743efde80) at /share/mozbuild/gecko-dev/js/src/jit/AsmJSSignalHandlers.cpp:963
#5  <signal handler called>
#6  mozilla::ScopedXErrorHandler::ScopedXErrorHandler (this=<optimized out>) at /share/mozbuild/gecko-dev/gfx/src/X11Util.cpp:62
#7  0x00007f275e7e0675 in mozilla::gl::CreateOffscreenPixmapContext (size=...) at /share/mozbuild/gecko-dev/gfx/gl/GLContextProviderGLX.cpp:1159
#8  0x00007f275e7e044e in mozilla::gl::GLContextProviderGLX::GetGlobalContext () at /share/mozbuild/gecko-dev/gfx/gl/GLContextProviderGLX.cpp:1256
#9  0x00007f275e7e0e44 in GetGlobalContextGLX () at /share/mozbuild/gecko-dev/gfx/gl/GLContextProviderGLX.cpp:943
#10 mozilla::gl::GLContextProviderGLX::CreateForWindow (aWidget=<optimized out>) at /share/mozbuild/gecko-dev/gfx/gl/GLContextProviderGLX.cpp:1086
#11 0x00007f275e8626d4 in mozilla::layers::CompositorOGL::CreateContext (this=this@entry=0x7f27381c9b20) at /share/mozbuild/gecko-dev/gfx/layers/opengl/CompositorOGL.cpp:123
#12 0x00007f275e86a742 in mozilla::layers::CompositorOGL::Initialize (this=0x7f27381c9b20) at /share/mozbuild/gecko-dev/gfx/layers/opengl/CompositorOGL.cpp:190
#13 0x00007f275e8667d9 in mozilla::layers::CompositorParent::InitializeLayerManager (this=this@entry=0x7f2741495000, aBackendHints=...) at /share/mozbuild/gecko-dev/gfx/layers/ipc/CompositorParent.cpp:935
#14 0x00007f275e86696c in mozilla::layers::CompositorParent::AllocPLayerTransactionParent (this=0x7f2741495000, aBackendHints=..., aId=<optimized out>, aTextureFactoryIdentifier=0x7f2743efea00, aSuccess=0x7f2743efe9ba)
    at /share/mozbuild/gecko-dev/gfx/layers/ipc/CompositorParent.cpp:957
#15 0x00007f275e39b7b9 in mozilla::layers::PCompositorParent::OnMessageReceived (this=0x7f2741495000, __msg=..., __reply=@0x7f2743efea70: 0x0) at /share/mozbuild/gecko-dev/obj-test/ipc/ipdl/PCompositorParent.cpp:829
#16 0x00007f275e2f213a in mozilla::ipc::MessageChannel::DispatchSyncMessage (this=0x7f2741495060, aMsg=...) at /share/mozbuild/gecko-dev/ipc/glue/MessageChannel.cpp:1079
#17 0x00007f275e2fa58a in mozilla::ipc::MessageChannel::OnMaybeDequeueOne (this=0x7f2741495060) at /share/mozbuild/gecko-dev/ipc/glue/MessageChannel.cpp:1051
#18 0x00007f275e2d0eae in MessageLoop::RunTask (this=0x7f2743efed48, task=0x7f27413c6560) at /share/mozbuild/gecko-dev/ipc/chromium/src/base/message_loop.cc:357
#19 0x00007f275e2d24da in MessageLoop::DeferOrRunPendingTask (this=<optimized out>, pending_task=...) at /share/mozbuild/gecko-dev/ipc/chromium/src/base/message_loop.cc:365
#20 0x00007f275e2d3a7a in MessageLoop::DoWork (this=0x7f2743efed48) at /share/mozbuild/gecko-dev/ipc/chromium/src/base/message_loop.cc:443
#21 0x00007f275e2d2eb5 in base::MessagePumpDefault::Run (this=0x7f2743f9de20, delegate=0x7f2743efed48) at /share/mozbuild/gecko-dev/ipc/chromium/src/base/message_pump_default.cc:34
#22 0x00007f275e2d2c60 in MessageLoop::RunInternal (this=this@entry=0x7f2743efed48) at /share/mozbuild/gecko-dev/ipc/chromium/src/base/message_loop.cc:229
#23 0x00007f275e2d2c92 in RunHandler (this=0x7f2743efed48) at /share/mozbuild/gecko-dev/ipc/chromium/src/base/message_loop.cc:222
#24 MessageLoop::Run (this=this@entry=0x7f2743efed48) at /share/mozbuild/gecko-dev/ipc/chromium/src/base/message_loop.cc:196
#25 0x00007f275e2dea1d in base::Thread::ThreadMain (this=0x7f274b34d1f0) at /share/mozbuild/gecko-dev/ipc/chromium/src/base/thread.cc:168
#26 0x00007f275e2c409c in ThreadFunc (closure=<optimized out>) at /share/mozbuild/gecko-dev/ipc/chromium/src/base/platform_thread_posix.cc:39
#27 0x00007f2762f9d0a4 in start_thread (arg=0x7f2743eff700) at pthread_create.c:309
#28 0x00007f27622ac04d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Comment 2

[Karl Tomlinson (:karlt)]

I wonder why tinderbox builds don't hit this assertion.
Is layers.acceleration.force-enabled set by default for B2G desktop, or just in your profile?

The fatal MOZ_ASSERT can be changed to a non-fatal NS_ASSERTION, if you like.

The consequences of the assertion failure are that race conditions can result in X11 errors that should be ignored causing aborts, or in removing the crash reporting error handler so we don't get crash reports for fatal errors.

Comment 3

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

They do show up, but since it only shows up in debug linux b2g desktop, the only way we /run/ that is hidden. If you turn on showall=1, you'll see tests fail on every build. Here's a sample log:

https://tbpl.mozilla.org/php/getParsedLog.php?id=44846629&tree=Mozilla-Central

I changed the assert to NS_ASSERTION and things ran fine, but yeah, it's a little disconcerting. However, if we're only hitting that code path on B2G Desktop, I could wrap the NS_ASSERTION in a b2g checker, and let it fail for everything else? Got a preference?

Comment 4

[Karl Tomlinson (:karlt)]

I see DispatchSyncMessage() on the stack, and WaitForSyncNotify() on the main thread, which actually makes this safe because the main thread is not doing anything else which this error handler manipulation is happening.

I'd like to modify the assertion to accept that situation.  MessageChannel knows when that is happening but I don't know how to get the MessageChannel.  CompositorParent makes the MessageLoop available but I don't know whether that is helpful.

Given the apparent difficultly there, I think the assertion should be converted to a warning, or backed out.

Comment 5

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

Attachment: Patch 1 (v1) - Change ScopedXErrorHandler assert to non-fatal

Comment 6

[Karl Tomlinson (:karlt)]

Comment on attachment 8464931 [details] [diff] [review]
Patch 1 (v1) - Change ScopedXErrorHandler assert to non-fatal

Thanks, Kyle.  Can you s/NS_ASSERTION/NS_WARN_IF_FALSE/ please?  This bug report demonstrates (and I now understand) that there is at least one case where off-main-thread use is done in a way that is safe.

Comment 7

[Karl Tomlinson (:karlt)]

Comment on attachment 8464931 [details] [diff] [review]
Patch 1 (v1) - Change ScopedXErrorHandler assert to non-fatal

>+    // This was a MOZ_ASSERT, but due to omtc this does manage to sometimes get
>+    // called off main thread. It's not fatal, but may cause issues, so we at
>+    // least warn when that happens.

Well, it could be fatal, so how about this comment:
"Off main thread usage is not safe in general, but OMTC GL layers uses this with the main thread blocked, which makes it safe."

Comment 8

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/72b1c5f4a0bb

Comment 9

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/72b1c5f4a0bb