1234026 - Firefox Nightly on Skype web site with e10s and XWayland tab has crashed on Fedora 23

Status: VERIFIED FIXED

(Core :: Graphics, defect)

Description

[Andrei Petcu]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20151219030215

Steps to reproduce:

Go to skype.com and try to sign in with Firefox Nightly (46.0a1 (2015-12-19)) on Fedora 23 and e10s enabled (it is enabled by default). After a few clicks I arrived on https://secure.skype.com/portal/overview


Actual results:

on "https://secure.skype.com/portal/overview" I got this message "Bad news first: This tab has crashed". I checked "Submit a crash report to help prevent more bad news" and clicked "Restore this tab".

I opened a new non-e10s window and it skype.com worked fine, I was also already signed in even if the e10s tab crashed.


Expected results:

Tab should not crash on skype.com.

Comment 1

[Andrei Petcu]

Are bugs that crash Firefox or a Firefox tab considered security issues?

Comment 2

[Felix]

User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20151219030215

Hello [e-mail],
This bug does not affect the Windows x64 Version of Firefox Nightly 46.0a1 (with security update 19.12.15) with e10s activated. And neither the Version you used (20151219030215) with Windows.
Maybe you/the next one should set the bug to Linux/Fedora only.

Felix

Comment 3

[Andrei Petcu]

Strange. Maybe it is Wayland only since it is kind of new? I downloaded the GNU/Linux Nightly build so it's not a Fedora packaging problem. Thank you for testing!

Comment 4

[Andrei Petcu]

Not sure if this is the same bug but it is similar https://bugzilla.mozilla.org/show_bug.cgi?id=1234071

Comment 5

[u279076]

Please provide crash report IDs from about:crashes. Comment 2 and 3 cannot be answered until we know what the crash reports say.

Comment 6

[u279076]

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #5)
> Please provide crash report IDs from about:crashes. Comment 2 and 3 cannot
> be answered until we know what the crash reports say.

Sorry bad c&p from bug 1234071. We do need to see your crash reports to debug this further though. Thanks.

Comment 7

[Andrei Petcu]

Here is my crash ID https://crash-stats.mozilla.com/report/index/f81df5c7-6971-4edf-89f5-e22c02151222 Hope this helps :)

Comment 8

[Kevin Brosnan [Ex-Mozilla]]

First interesting line in the stack is GFX so placing there for now. Stransky this is a Fedora 23 crash, not sure if you want to pursue this.

Comment 10

[Andrei Petcu]

I have another crash. https://crash-stats.mozilla.com/report/index/d78b5a42-9b95-46ad-9969-360c62151222 this one on a Mozilla web site https://developer.mozilla.org/en-US/docs/Tools/Performance

Comment 11

[Andrei Petcu]

I tested both URLs above + this one I put in the duplicate bug https://motherboard.vice.com/en_uk/read/star-citizen-is-now-a-100-million-crowdfunded-game on the exact same system only I booted into Gnome+X11 not Gnome+Wayland so it is a Wayland issue for sure.

Comment 12

[u279076]

I can reproduce this on Firefox 46.0a1 and 45.0a2 with e10s enabled, however this does not reproduce with Firefox 41.0a1 from October 23, 2015 with e10s enabled. Note that you need to go through the sign-in flow on Skype.com to reproduce this; it's not enough to simply load https://secure.skype.com/portal/overview.

I'll use mozregression to narrow this down.

Comment 13

[u279076]

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #12)
> this does not reproduce with Firefox 41.0a1 from October 23, 2015

Sorry, this build is actually from June 1, 2015 (misread the date). Still working on the range.

Comment 14

[u279076]

Looks like this started in Firefox 42 when we switched over to GTK+3:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1ee54e043b9b05d69e6a9f981aa6c4ef0dd65be3&tochange=939320b957c588ad809e9b4a64b7f232dd4d9b72

Mike or Lee, do you have any insight into what might be happening here?

Comment 15

[Lee Salzman [:lsalzman]]

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #14)
> Looks like this started in Firefox 42 when we switched over to GTK+3:
> https://hg.mozilla.org/integration/mozilla-inbound/
> pushloghtml?fromchange=1ee54e043b9b05d69e6a9f981aa6c4ef0dd65be3&tochange=9393
> 20b957c588ad809e9b4a64b7f232dd4d9b72
> 
> Mike or Lee, do you have any insight into what might be happening here?

Looks like it is trying to query some symbol from libGL or similar and somehow getting junk.

Comment 16

[Mike Hommey [:glandium]]

Frame 0 being unsymbolized, the following frames might as well be red herrings, so it's really hard to tell anything. It would be useful to get an actual stack trace from a local gdb, with debugging symbols for system libraries and firefox (you can get debugging symbols for firefox with fetch-symbols: http://hg.mozilla.org/users/jwatt_jwatt.org/fetch-symbols )

Comment 17

[u279076]

Here is the gdb stack, thanks for your help Mike:

#0  0x00007fc598b170e9 in XQueryExtension (dpy=dpy@entry=0x7fc58fe17010, name=name@entry=0x7fc595c52648 <__glXExtensionName> "GLX", major_opcode=major_opcode@entry=0x7ffddc76d184, first_event=first_event@entry=0x7ffddc76d188, first_error=first_error@entry=0x7ffddc76d18c) at QuExt.c:43
#1  0x00007fc598b0ac52 in XInitExtension (dpy=dpy@entry=0x7fc58fe17010, name=name@entry=0x7fc595c52648 <__glXExtensionName> "GLX") at InitExt.c:47
#2  0x00007fc595bfa6fc in __glXInitialize (dpy=0x7fc58fe17010) at glxext.c:848
#3  0x00007fc595bf60a1 in glXQueryVersion (dpy=<optimized out>, major=0x7fc5a2dda814 <mozilla::gl::sGLXLibrary+180>, minor=0x7fc5a2dda818 <mozilla::gl::sGLXLibrary+184>) at glxcmds.c:487
#4  0x00007fc59f05de36 in mozilla::gl::GLXLibrary::xQueryVersion (minor=0x7fc5a2dda818 <mozilla::gl::sGLXLibrary+184>, major=0x7fc5a2dda814 <mozilla::gl::sGLXLibrary+180>, display=0x7fc58fe17010, this=0x7fc5a2dda760 <mozilla::gl::sGLXLibrary>) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/gfx/gl/GLContextProviderGLX.cpp:685
#5  mozilla::gl::GLXLibrary::EnsureInitialized (this=this@entry=0x7fc5a2dda760 <mozilla::gl::sGLXLibrary>) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/gfx/gl/GLContextProviderGLX.cpp:180
#6  0x00007fc59f05eb8a in mozilla::gl::CreateOffscreenPixmapContext (minCaps=..., profile=profile@entry=mozilla::gl::ContextProfile::OpenGLCompatibility, size=...) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/gfx/gl/GLContextProviderGLX.cpp:1219
#7  0x00007fc59f05efbf in mozilla::gl::GLContextProviderGLX::CreateOffscreen (size=..., minCaps=..., flags=flags@entry=mozilla::gl::CreateContextFlags::REQUIRE_COMPAT_PROFILE) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/gfx/gl/GLContextProviderGLX.cpp:1303
#8  0x00007fc59f876a17 in mozilla::CreateGLWithDefault (caps=..., flags=mozilla::gl::CreateContextFlags::REQUIRE_COMPAT_PROFILE, webgl=0x7fc57a921000) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/dom/canvas/WebGLContext.cpp:600
#9  0x00007fc59f8866e1 in mozilla::WebGLContext::CreateAndInitGLWith (this=this@entry=0x7fc57a921000, fnCreateGL=fnCreateGL@entry=0x7fc59f876939 <mozilla::CreateGLWithDefault(mozilla::gl::SurfaceCaps const&, mozilla::gl::CreateContextFlags, mozilla::WebGLContext*)>, baseCaps=..., flags=flags@entry=mozilla::gl::CreateContextFlags::REQUIRE_COMPAT_PROFILE) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/dom/canvas/WebGLContext.cpp:628
#10 0x00007fc59f886956 in mozilla::WebGLContext::CreateAndInitGL (this=this@entry=0x7fc57a921000, forceEnabled=forceEnabled@entry=false) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/dom/canvas/WebGLContext.cpp:677
#11 0x00007fc59f887db9 in mozilla::WebGLContext::SetDimensions (this=0x7fc57a921000, signedWidth=<optimized out>, signedHeight=<optimized out>) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/dom/canvas/WebGLContext.cpp:843
#12 0x00007fc59f852d9b in mozilla::dom::CanvasRenderingContextHelper::UpdateContext (this=0x7fc577fd8e90, aCx=0x7fc57a93c000, aNewContextOptions=..., aRvForDictionaryInit=...) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/dom/canvas/CanvasRenderingContextHelper.cpp:238
#13 0x00007fc59f856d11 in mozilla::dom::CanvasRenderingContextHelper::GetContext (this=this@entry=0x7fc577fd8e90, aCx=0x7fc57a93c000, aContextId=..., aContextOptions=..., aRv=...) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/dom/canvas/CanvasRenderingContextHelper.cpp:196
#14 0x00007fc59f93c249 in mozilla::dom::HTMLCanvasElement::GetContext (this=this@entry=0x7fc577fd8e00, aCx=aCx@entry=0x7fc57a93c000, aContextId=..., aContextOptions=..., aContextOptions@entry=..., aRv=...) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/dom/html/HTMLCanvasElement.cpp:892
#15 0x00007fc59f79876f in mozilla::dom::HTMLCanvasElementBinding::getContext (cx=cx@entry=0x7fc57a93c000, obj=..., obj@entry=..., self=0x7fc577fd8e00, args=...) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/obj-firefox/dom/bindings/HTMLCanvasElementBinding.cpp:224
#16 0x00007fc59e7a51b0 in mozilla::dom::GenericBindingMethod (cx=0x7fc57a93c000, argc=<optimized out>, vp=<optimized out>) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/dom/bindings/BindingUtils.cpp:2718
#17 0x00007fc59e963606 in js::CallJSNative (args=..., native=0x7fc59e7a50d0 <mozilla::dom::GenericBindingMethod(JSContext*, unsigned int, JS::Value*)>, cx=0x7fc57a93c000) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/js/src/jscntxtinlines.h:235
#18 js::Invoke (cx=0x7fc57a93c000, args=..., construct=<optimized out>) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/js/src/vm/Interpreter.cpp:460
#19 0x00007fc59e956800 in Interpret (cx=0x7fc57a93c000, state=...) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/js/src/vm/Interpreter.cpp:2786
#20 0x00007fc59e963344 in js::RunScript (cx=cx@entry=0x7fc57a93c000, state=...) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/js/src/vm/Interpreter.cpp:407
#21 0x00007fc5a0b51c28 in js::ExecuteKernel (cx=cx@entry=0x7fc57a93c000, script=..., scopeChainArg=..., newTargetValue=..., type=<optimized out>, evalInFrame=..., evalInFrame@entry=..., result=0x0) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/js/src/vm/Interpreter.cpp:666
#22 0x00007fc5a0b51d3c in js::Execute (cx=cx@entry=0x7fc57a93c000, script=..., script@entry=..., scopeChainArg=..., rval=<optimized out>) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/js/src/vm/Interpreter.cpp:701
#23 0x00007fc5a0aac570 in Evaluate (cx=cx@entry=0x7fc57a93c000, scope=..., staticScope=..., staticScope@entry=..., optionsArg=..., srcBuf=..., rval=...) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/js/src/jsapi.cpp:4406
#24 0x00007fc5a0aae148 in Evaluate (cx=cx@entry=0x7fc57a93c000, scopeChain=..., optionsArg=..., srcBuf=..., rval=...) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/js/src/jsapi.cpp:4432
#25 0x00007fc5a0aae17a in JS::Evaluate (cx=cx@entry=0x7fc57a93c000, scopeChain=..., optionsArg=..., srcBuf=..., rval=..., rval@entry=...) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/js/src/jsapi.cpp:4493
#26 0x00007fc59e79ae5a in nsJSUtils::EvaluateString (aCx=aCx@entry=0x7fc57a93c000, aSrcBuf=..., aEvaluationGlobal=..., aEvaluationGlobal@entry=..., aCompileOptions=..., aEvaluateOptions=..., aRetValue=..., aOffThreadToken=0x0) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/dom/base/nsJSUtils.cpp:224
#27 0x00007fc59f293e29 in nsJSUtils::EvaluateString (aCx=0x7fc57a93c000, aSrcBuf=..., aEvaluationGlobal=aEvaluationGlobal@entry=..., aCompileOptions=..., aOffThreadToken=<optimized out>) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/dom/base/nsJSUtils.cpp:287
#28 0x00007fc59f2a23f2 in nsScriptLoader::EvaluateScript (this=this@entry=0x7fc568d0c390, aRequest=aRequest@entry=0x7fc565559580, aSrcBuf=...) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/dom/base/nsScriptLoader.cpp:1153
#29 0x00007fc59f2a2fa2 in nsScriptLoader::ProcessRequest (this=this@entry=0x7fc568d0c390, aRequest=0x7fc565559580) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/dom/base/nsScriptLoader.cpp:971
#30 0x00007fc59f2aa0cc in nsScriptLoader::ProcessScriptElement (this=0x7fc568d0c390, aElement=aElement@entry=0x7fc5767bf390) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/dom/base/nsScriptLoader.cpp:649
#31 0x00007fc59f2aa58d in nsScriptElement::MaybeProcessScript (this=0x7fc5767bf390) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/dom/base/nsScriptElement.cpp:142
#32 0x00007fc59effbde6 in nsIScriptElement::AttemptToExecute (this=0x7fc5767bf390) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/dom/base/nsIScriptElement.h:221
#33 0x00007fc59f013452 in nsHtml5TreeOpExecutor::RunScript (this=this@entry=0x7fc568c8ec00, aScriptElement=<optimized out>) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/parser/html/nsHtml5TreeOpExecutor.cpp:666
#34 0x00007fc59e7597ea in nsHtml5TreeOpExecutor::RunFlushLoop (this=0x7fc568c8ec00) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/parser/html/nsHtml5TreeOpExecutor.cpp:491
#35 0x00007fc59f0136bd in nsHtml5ExecutorReflusher::Run (this=<optimized out>) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/parser/html/nsHtml5TreeOpExecutor.cpp:58
#36 0x00007fc59e70fec9 in nsThread::ProcessNextEvent (this=0x7fc58fe7c9d0, aMayWait=<optimized out>, aResult=0x7ffddc76f890) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/xpcom/threads/nsThread.cpp:964
#37 0x00007fc59e717d5e in NS_ProcessNextEvent (aThread=<optimized out>, aMayWait=aMayWait@entry=false) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/xpcom/glue/nsThreadUtils.cpp:297
#38 0x00007fc59e72ed63 in mozilla::ipc::MessagePump::Run (this=0x7fc58febc060, aDelegate=0x7ffddc76faa0) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/ipc/glue/MessagePump.cpp:95
#39 0x00007fc59ec84af3 in MessageLoop::RunInternal (this=<optimized out>) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/ipc/chromium/src/base/message_loop.cc:234
#40 MessageLoop::RunHandler (this=<optimized out>) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/ipc/chromium/src/base/message_loop.cc:227
#41 MessageLoop::Run (this=<optimized out>) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/ipc/chromium/src/base/message_loop.cc:201
#42 0x00007fc59fd671f8 in nsBaseAppShell::Run (this=0x7fc57ebc7a40) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/widget/nsBaseAppShell.cpp:156
#43 0x00007fc5a03a1f72 in XRE_RunAppShell () at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/toolkit/xre/nsEmbedFunctions.cpp:787
#44 0x00007fc59ec84af3 in MessageLoop::RunInternal (this=0x7ffddc76e760) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/ipc/chromium/src/base/message_loop.cc:234
#45 MessageLoop::RunHandler (this=0x7ffddc76e760) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/ipc/chromium/src/base/message_loop.cc:227
#46 MessageLoop::Run (this=this@entry=0x7ffddc76faa0) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/ipc/chromium/src/base/message_loop.cc:201
#47 0x00007fc5a03a264c in XRE_InitChildProcess (aArgc=7, aArgv=<optimized out>, aGMPLoader=<optimized out>) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/toolkit/xre/nsEmbedFunctions.cpp:623
#48 0x000000000040c671 in content_process_main (argc=<optimized out>, argv=0x7ffddc770e08) at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/ipc/app/../contentproc/plugin-container.cpp:237
#49 0x00007fc59cc5d580 in __libc_start_main (main=0x408990 <main(int, char**)>, argc=10, argv=0x7ffddc770e08, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffddc770df8) at libc-start.c:289
#50 0x000000000040bed1 in _start ()

Comment 18

[Mike Hommey [:glandium]]

Some more information from the debugging session with Anthony:

The disassembly around the crash point is:
   0x00007fc598b170dd <+45>:    mov    0x968(%rdi),%rax
   0x00007fc598b170e4 <+52>:    test   %rax,%rax
   0x00007fc598b170e7 <+55>:    je     0x7fc598b170eb <XQueryExtension+59>
=> 0x00007fc598b170e9 <+57>:    callq  *(%rax)

%rdi is 0x7fc58fe17010, which is the dpy argument from the call to XQueryExtension, inherited from the display argument to mozilla::gl::GLXLibrary::xQueryVersion, called from mozilla::gl::GLXLibrary::EnsureInitialized in gfx/gl/GLContextProviderGLX.cpp.

The code around that function call looks like:

   Display *display = DefaultXDisplay();
   int screen = DefaultScreen(display);

   if (!xQueryVersion(display, &mGLXMajorVersion, &mGLXMinorVersion)) {

so the display argument comes from DefaultXDisplay, which reads (once preprocessed):

   inline Display*
   DefaultXDisplay()
   {
     return GDK_DISPLAY_XDISPLAY(gdk_display_get_default());
   }

The data in that display looks like garbage:
   {ext_data = 0x7fc58fea5330, free_funcs = 0x1, fd = 2084414128, conn_checker = 32709, proto_major_version = 2068823008, proto_minor_version = 32709, vendor = 0x4058000000000000 <error: Cannot access memory at address 0x4058000000000000>, resource_base = 0, resource_mask = 140486500061184, resource_id = 140486500061552, resource_shift = 1425, resource_alloc = 0x0, byte_order = -1880938496, bitmap_unit = 32709, bitmap_pad = -1881097216, bitmap_bit_order = 32709, nformats = 0, pixmap_format = 0x7fc58fe328c0, vnumber = 1, release = 1, head = 0x18000, tail = 0x7fc59790b162, qlen = -1752108504, last_request_read = 1, request = 0, last_req = 0x7562642f706d742f <error: Cannot access memory at address 0x7562642f706d742f>, buffer = 0x72563462397a2d73 <error: Cannot access memory at address 0x72563462397a2d73>, bufptr = 0x50556342 <error: Cannot access memory at address 0x50556342>, bufmax = 0x0, max_request_size = 0, db = 0x0, synchandler = 0x0, display_name = 0x0, default_screen = 0, nscreens = 0, screens = 0x0, motion_buffer = 0, flags = 0, min_keycode = 0, max_keycode = 0, keysyms = 0x0, modifiermap = 0x14, keysyms_per_keycode = 3, xdefaults = 0x7fc58fe4f2a0 "@\260\347\217\305\177", scratch_buffer = 0x1 <error: Cannot access memory at address 0x1>, scratch_length = 0, ext_number = -1881050960, ext_procs = 0x0, event_vec = {0x0, 0x0, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0xffffffff00000000, 0x2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7fc58fe17150, 0x0, 0x0, 0x0, 0x25e, 0x7fc584c40790, 0x7fc597ee2edb, 0xe3, 0x54, 0x7fc584c60140, 0x7fc597ee2ec7, 0x7fc597ee2e80, 0x0, 0x4, 0x7fc584c2aa70, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0xffffffff00000000, 0x2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7fc58fe17290, 0x7fc58fe17150, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0xffffffff00000000, 0x2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7fc58fe17330, 0x7fc57c340700, 0x7fc57b935040, 0x7fc57c3360c0, 0x7fc57c340a40, 0x7fc57c3364c0, 0x7fc57c340cc0, 0x0, 0xffffffff, 0xbff0000000000000, 0x0, 0x0, 0x0, 0x7fc58fee2840, 0x1, 0x7fc57c3fd460, 0x7fc58fe173d0, 0x1, 0x4058000000000000, 0x7fc584c1c790, 0x0, 0x5, 0x0, 0x0, 0x1, 0x0, 0x7fc57b703010, 0x0, 0x0, 0x0, 0xffffffff00000004, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7fc57b926980, 0x1, 0x0, 0x7fc58fe17470, 0x7fc58fe17330, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, wire_vec = {0x0, 0x0, 0x0, 0x0, 0x0, 0x800000000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7fc58fe17290, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0xffffffff00000000, 0x2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7fc58fe175b0, 0x0, 0x0, 0x0, 0x200ff, 0x7fc59a084e70 <g_variant_type_info_basic_table+272>, 0x0, 0x0, 0x200ff, 0x7fc59a084d60 <g_variant_type_info_basic_table>, 0x1, 0x0, 0xff, 0x7fc59a084dd0 <g_variant_type_info_basic_table+112>, 0x1, 0x4, 0xfc, 0x7fc58fe0e630, 0x1, 0xc, 0x100f8, 0x7fc57b937d80, 0x0, 0x7, 0x0, 0x7fc57c396230, 0x0, 0x7fc58feed840, 0x1, 0x0, 0x0, 0x0, 0x0, 0x44, 0x7fc57b938f00, 0x0, 0x7fc58fe17710, 0x7fc58fe17700, 0x7fc58fe176f0, 0x0, 0x7fc58fe176f0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xc, 0x7fc58fe1f7d0, 0x7fc58fe1f7d0, 0x0, 0x0, 0xe5e5e5e5e5e5e5e5 <repeats 12 times>, 0x7fc58fe1e830, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7fc58fe70b30, 0x538ba5c9a, 0x0, 0x0, 0x1, 0x7fc598effe60 <write_message_cb>, 0x7fc584c4dc90, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0xe5e5e5e5e5e5e5e5, 0x7fc58fe209c0, 0x7fc58fe20dd0, 0x0, 0x0, 0x0}, lock_meaning = 0, lock = 0x0, async_handlers = 0x0, bigreq_size = 0, lock_fns = 0x1, idlist_alloc = 0x2, key_bindings = 0x0, cursor_font = 140486169027328, atoms = 0x0, mode_switch = 0, num_lock = 0, context_db = 0x0, error_vec = 0x0, cms = {defaultCCCs = 0x7fc57b937c20 " v\223{\305\177", clientCmaps = 0x1 <error: Cannot access memory at address 0x1>, perVisualIntensityMaps = 0x0}, im_filters = 0x0, qfree = 0x200400310, next_event_serial_num = 0, flushes = 0x0, im_fd_info = 0x0, im_fd_length = -437918235, conn_watchers = 0x7fc57b87dc10, watcher_count = 0, filedes = 0x0, savedsynchandler = 0x0, resource_max = 0, xcmisc_opcode = 0, xkb_info = 0x0, trans_conn = 0x0, xcb = 0x0, next_cookie = 0, generic_event_vec = {0x2, 0x0, 0x7fc57b8bb1e0, 0x0, 0x0, 0x0, 0x0, 0x7fc57b938760, 0x1, 0x0, 0x0, 0x200400310, 0x0, 0x0, 0x0, 0xe5e5e5e5e5e5e5e5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2, 0x0, 0x7fc57b8b36a0, 0x0, 0x0, 0x0, 0x0, 0x7fc57b938920, 0x1, 0x0, 0x7fc57c3b3170, 0x200400310, 0x7fc57b8ba000, 0x1, 0x7fc5734e68c0, 0xe5e5e5e5e5e5e5e5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1, 0x2, 0x0, 0x7fc57c341400, 0x0, 0x0, 0x0, 0x0, 0x7fc57b9389a0, 0x1, 0x0, 0x7fc57b9fe520, 0x200400310, 0x7fc57b8ba000, 0x1, 0x7fc579861f80, 0xe5e5e5e5e5e5e5e5, 0x7fc58fe17ee0, 0x0, 0x0, 0x0, 0x0, 0x7fc58fe0fd40, 0x7fc598efe120 <read_with_control_data_free>, 0x7fc58fe70b30, 0x538ba5e9d, 0x0, 0x0, 0x1, 0x7fc598f00040 <_g_dbus_worker_do_read_cb>, 0x7fc58fea1480, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x454, 0x0, 0x0, 0xe5e5e5e5e5e5e5e5, 0x7fc58fe1eb70, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7fc58fe70b30, 0x538ba5ba8, 0x0, 0x0, 0x1, 0x7fc598effe60 <write_message_cb>, 0x7fc584c4db90, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0xe5e5e5e5e5e5e5e5, 0x7fc58fe4a860, 0x2, 0x0, 0x7fc58fef7280, 0x0, 0x7fc58fe0fe80, 0x7fc598efe120 <read_with_control_data_free>, 0x7fc58fe70b30}, generic_event_copy_vec = {0x538ba5f1b, 0x0, 0x7fc58fe0b480, 0x1, 0x7fc598f00040 <_g_dbus_worker_do_read_cb>, 0x7fc58fea1480, 0x0 <repeats 11 times>, 0xe5e5e5e5e5e5e5e5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7fc58fe0d0e0, 0x7fc598efe120 <read_with_control_data_free>, 0x7fc58fe70b30, 0x538a8e125, 0x0, 0x0, 0x1, 0x7fc598f00040 <_g_dbus_worker_do_read_cb>, 0x7fc58fea1480, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, 0x0, 0xe5e5e5e5e5e5e5e5, 0xe5e5e5e5e5e5e5e5, 0xe5e5e5e5e5e5e5e5, 0xe5e5e5e5e5e5e5e5, 0xe5e5e5e5e5e5e5e5, 0x0, 0xe5e5e5e500000009, 0x7fc58fe1efd0, 0x7fc57b87dfd0, 0xe5e5e5e5e5e5e5e5, 0xe5e5e5e5e5e5e5e5, 0x7fc58fe18010, 0x7fc58fe18400, 0x7fc58fe06700, 0x5, 0x7fc58fe0fa40, 0x2a, 0x7fc57e7bf860, 0x16, 0x7fc58fed3700, 0x13, 0x7fc58fed4000, 0x4, 0x7fc58fed4400, 0x7, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7fc58fe1f010, 0x8, 0x0, 0x0, 0x0, 0x0, 0x7fc58fe17860, 0x7, 0x0 <repeats 46 times>}, cookiejar = 0x0}

And the crash happens on using the lock_fns field, which is 0x1.

I guess the fact that the display is in fact Wayland is not helping here.

We still have dependencies on having a X display, and I'm not surprised we don't work entirely in Wayland. We may want, if we can (can we?) to force GTK to use X even under Wayland, until we have proper support for Wayland.

Comment 19

[Mike Hommey [:glandium]]

Bug 1215085 is related.

Comment 20

[Mike Hommey [:glandium]]

Note this is something we need to handle somehow because, while I think on Fedora 23, Wayland is not the default, it's set to be in F24.

Comment 21

[Mike Hommey [:glandium]]

https://developer.gnome.org/gdk3/stable/gdk3-General.html#gdk-set-allowed-backends

"Since 3.10" sigh.

I guess we can set GDK_BACKEND to x11 before initializing Gtk...

Comment 22

[u279076]

(In reply to Mike Hommey [:glandium] from comment #20)
> Note this is something we need to handle somehow because, while I think on
> Fedora 23, Wayland is not the default, it's set to be in F24.

That is correct, at least according to https://fedoraproject.org/wiki/Changes/WaylandByDefault. However I don't see it mentioned on their list of proposed changes https://fedoraproject.org/wiki/Releases/24. Would it be worth notifying Red Hat folks other than Stansky about this (eg. WaylandByDefault owners)?

Comment 23

[Mike Hommey [:glandium]]

So, I was able to reproduce the same crash with some random webgl demo on MDN. I could get the crash to go away by running with GDB_BACKEND=x11 and DISPLAY=:0 (without setting DISPLAY, Gtk complains it can't open the display "Wayland" ; that means some complication because we'd need to find the right DISPLAY to set for the right instance of XWayland).

But the real surprise is that without those env variables, so supposedly with pure wayland, webgl *is* working in a non-e10s window. So not only does it not crash, but GLX actually works. O_o

Comment 24

[Mike Hommey [:glandium]]

This is getting interesting...

$ GDK_BACKEND= DISPLAY=Wayland ./firefox
Unable to init server: Broadway display type not supported: Wayland
Error: cannot open display: Wayland

So, in fact, the firefox I was running where GLX was working was actually running on XWayland. We are, in fact, being forced to run on XWayland somehow, but that somehow doesn't seem to work properly in the child process, although DISPLAY *is* set to :0 in both processes.

Comment 25

[Mike Hommey [:glandium]]

If I unset XDG_RUNTIME_DIR, I get the same effect as setting GDK_BACKEND to "x11" when DISPLAY is already ":0" : the crash goes away and GLX works.

Comment 26

[Mike Hommey [:glandium]]

So this all comes down to this:
- in the main process, gdk_display_manager_open_display is called from gdk_display_open, which we call from  XREMain::XRE_mainStartup, and is passed the display name (":0") down from there, which makes the GDK display manager choose the X11 backend.
- in the content process, gdk_display_manager_open_display is called from gtk_init, which we call from ContentChild::Init, and in that case, it's not passed a display name, so GDK happily picks the wayland backend.

Comment 27

[Mike Hommey [:glandium]]

Attachment: Pass a --display option to gtk_init in content processes

Comment 28

[Mike Hommey [:glandium]]

Anthony, can you test this build when it's up?
https://treeherder.mozilla.org/#/jobs?repo=try&revision=9360d5959a97

Comment 29

[u279076]

(In reply to Mike Hommey [:glandium] from comment #28)
> Anthony, can you test this build when it's up?
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=9360d5959a97

Sure, I'll give this a shot tomorrow when I'm back at my workstation.

Comment 30

[Andrei Petcu]

(In reply to Mike Hommey [:glandium] from comment #28)
> Anthony, can you test this build when it's up?
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=9360d5959a97

I will check it out soon. Thank you!

Comment 31

[u279076]

(In reply to Mike Hommey [:glandium] from comment #28)
> Anthony, can you test this build when it's up?
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=9360d5959a97

This build does not crash for me.

Comment 32

[Andrei Petcu]

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #31)
> (In reply to Mike Hommey [:glandium] from comment #28)
> > Anthony, can you test this build when it's up?
> > https://treeherder.mozilla.org/#/jobs?repo=try&revision=9360d5959a97
> 
> This build does not crash for me.

N00b here. How do I try this build? I don't see a download button. Should I build Firefox myself from one of these revisions? Thank you!

Comment 33

[Andrei Petcu]

I made a bug in Fedora's Bugzilla so Fedora community knows about this. https://bugzilla.redhat.com/show_bug.cgi?id=1294057

Comment 34

[u279076]

Hi Andrei,

To test the build you would click the treeherder link then click the left-side green 'B' beside either Linux opt or Linux x64 opt (I chose x64 because I'm testing 64-bit Fedora). At this point a bottom panel will open on the page with two panes. The left-side pane will show "Build:" with a link to the build. This will open a new tab to a folder on archive.mozilla.org with the tar.bz2 to download. Extract this and run the build.

Skipping all that you can just download http://archive.mozilla.org/pub/firefox/try-builds/[e-mail]-9360d5959a9750deaa7e224f9a77a92beffe57d7/try-linux64/firefox-46.0a1.en-US.linux-x86_64.tar.bz2 to test. That said, having you test this build is unnecessary given that I already tested it in comment 31.

Thank you for filing the bug report on Redhat's end.

Comment 35

[Andrei Petcu]

> (In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #34)
> That said, having you test this build is unnecessary given that I already tested it in comment 31.
Thank you for the info!
I see the futility in my testing, but I tested the build anyway! It works well on all 3 broken web sites.

> Thank you for filing the bug report on Redhat's end.
No problem ;) I will also close it on their end when this will be fixed in nightly.

Please ELI5 this for me: what was the problem, what was the fix?

Comment 36

[Mike Hommey [:glandium]]

(In reply to andrei from comment #35)
> Please ELI5 this for me: what was the problem

See comment 26.

> what was the fix?

See patch comment.

Comment 37

[Andrei Petcu]

Thank you!

Comment 38

[Karl Tomlinson (:karlt)]

Comment on attachment 8701315 [details] [diff] [review]
Pass a --display option to gtk_init in content processes

This should be fine for now at least, thanks.  I expect it will need more
attention eventually for the sake of bug 1215078.

>+    // We could use gdk_display_open, and gdk_display_manager_set_default_display
>+    // but then we'd have to hold onto it and gdk_display_close it at the
>+    // right moment, so it's simpler to just pass down a fake argv list.

Please remove either the part about gdk_display_close and simpler or this
whole sentence.  gtk_init() won't schedule closing its display for us and so
is not really better in that sense and the const_cast means that it is not
entirely simpler.

>+    const char *display_name = PR_GetEnv("DISPLAY");

>+        const char *argv[] = {
>+            nullptr,
>+            "--display",
>+            display_name,
>+            nullptr
>+        };
>+        char** argv_ = const_cast<char**>(argv);

'*' by the type, rather than the variable name, is the newer style.

Would removing const from display_name and using char option_name[] =
"--display" make the const_cast unnecessary?

(In reply to Mike Hommey [:glandium] (VAC: 31 Dec - 11 Jan) from comment #21)
> https://developer.gnome.org/gdk3/stable/gdk3-General.html#gdk-set-allowed-
> backends
> 
> "Since 3.10" sigh.

Although there is the inconvenience of having to use dlsym, I think using this
would also be fine as I don't expect WAYLAND_DISPLAY to be set on a typical
system with GTK+ older than 3.10, but setting the display name explicitly, as in this patch, is more consistent with what nsAppRunner is doing.

Comment 39

[Mike Hommey [:glandium]]

(In reply to Karl Tomlinson (ni?:karlt) from comment #38)
> Would removing const from display_name and using char option_name[] =
> "--display" make the const_cast unnecessary?

That would make the code effectively do the equivalent of:
char option_name[sizeof("--display")];
memcpy(option_name, "--display", sizeof("--display"));

Is that desirable?

Comment 40

[Karl Tomlinson (:karlt)]

(In reply to Mike Hommey (VAC: 31 Dec - 11 Jan) [:glandium] from comment #39)
> (In reply to Karl Tomlinson (ni?:karlt) from comment #38)
> > Would removing const from display_name and using char option_name[] =
> > "--display" make the const_cast unnecessary?
> 
> That would make the code effectively do the equivalent of:
> char option_name[sizeof("--display")];
> memcpy(option_name, "--display", sizeof("--display"));
> 
> Is that desirable?

I don't think it would cause any harm.

Although it seems unlikely that gtk_init would even temporarily write to this string, writing to read-only data would cause harm.

Maybe it doesn't matter.  I don't know.

Comment 41

[Mike Hommey [:glandium]]

(In reply to Karl Tomlinson (ni?:karlt) from comment #38)
> Would removing const from display_name and using char option_name[] =
> "--display" make the const_cast unnecessary?

So it turns out that this doesn't work without a reinterpret_cast because:
  ContentChild.cpp:639:5: error: no matching function for call to 'gtk_init'
  gtkmain.h:101:10: note: candidate function not viable: no known conversion from 'char *(*)[4]' to 'char ***' for 2nd argument

In the end, this is what it looks like without const:

char* display_name = PR_GetEnv("DISPLAY");
if (display_name) {
  int argc = 3;
  char option_name[] = "--display";
  char* argv[] = {
    nullptr,
    option_name,
    display_name,
    nullptr
  };
  gtk_init(&argc, reinterpret_cast<char***>(&argv));
} else {
  gtk_init(nullptr, nullptr);
}

Which do you prefer? const or not?

Comment 42

[Karl Tomlinson (:karlt)]

(In reply to Mike Hommey (VAC: 31 Dec - 11 Jan) [:glandium] from comment #41)
>   ContentChild.cpp:639:5: error: no matching function for call to 'gtk_init'
>   gtkmain.h:101:10: note: candidate function not viable: no known conversion
> from 'char *(*)[4]' to 'char ***' for 2nd argument

>   char* argv[] = {
>     nullptr,
>     option_name,
>     display_name,
>     nullptr
>   };
>   gtk_init(&argc, reinterpret_cast<char***>(&argv));

gtk_init's second argument is of type char*** because it wants to be able to modify the char** pointer to the first char* element in the array (though I don't expect it ever removes argv0, so I doubt it actually modifies the char** pointer, only the char* pointers).

Because argv is an array, &argv merely converts to char** pointer, which is
equivalent to the implicit conversion to pointer without the &.
The reinterpret_cast above is incorrect and not necessary when gtk_init is
passed a pointer to a char** variable that it can modify:

    char** argvp = argv;
    gtk_init(&argc, &argvp);

I prefer this over requiring a const_cast because it is relatively easy to incorrectly cast the wrong thing with all these pointers.

Comment 43

[Mike Hommey [:glandium]]

(In reply to Karl Tomlinson (ni?:karlt) from comment #42)
> gtk_init's second argument is of type char*** because it wants to be able to
> modify the char** pointer to the first char* element in the array (though I
> don't expect it ever removes argv0, so I doubt it actually modifies the
> char** pointer, only the char* pointers).
> 
> Because argv is an array, &argv merely converts to char** pointer, which is
> equivalent to the implicit conversion to pointer without the &.

Aah. facedesk with shame.

Comment 44

[Karl Tomlinson (:karlt)]

(In reply to Mike Hommey (VAC: 31 Dec - 11 Jan) [:glandium] from comment #43)
> facedesk with shame.

I wonder whether this makes sense in the language authors' minds or they feel the same way.

Comment 45

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/267b941dabd4

Comment 46

[Mike Hommey [:glandium]]

Comment on attachment 8701315 [details] [diff] [review]
Pass a --display option to gtk_init in content processes

Approval Request Comment
[Feature/regressing bug #]: Switch to Gtk+3
[User impact if declined]: Content process crash when using WebGL on XWayland with e10s enabled. It's not going to be a problem on released 45 because e10s is not riding the trains, but it is a crasher on current aurora, where Gtk+3 and e10s are both enabled.
[Describe test coverage new/current, TreeHerder]: This is how I tested this without running a full wayland desktop:
- launch `weston` from a X session
- launch `Xwayland :42`
- launch `DISPLAY=:42 firefox`
- open a web page using webGL. I've been using https://developer.mozilla.org/en-US/demos/detail/sechelt/launch
[Risks and why]: Very low. In practice, it doesn't change anything when running on "native" X11.
[String/UUID change made/needed]: None

Comment 47

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/267b941dabd4

Comment 48

[u279076]

Andrei, this should be fixed in today's Nightly build. Can you please verify it is working for you now?

Comment 49

[Andrei Petcu]

Tested on all 3 web sites and it is ok :)

Comment 50

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8701315 [details] [diff] [review]
Pass a --display option to gtk_init in content processes

Sure, let's take it.

Comment 51

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/69c01f698fd0

Comment 52

[u279076]

(In reply to andrei from comment #49)
> Tested on all 3 web sites and it is ok :)

Thanks for your help! By the way, this should be fixed in tomorrow's Aurora build as well.