1399734 - Shutdown hang in alert()

Status: RESOLVED WONTFIX

(Core :: DOM: Content Processes, defect, P3)

Description

Attachment: Windows Opt Log

1. <contact me for the url if you are working on this bug>

2. Click Ok in Alert.

3. Browser Window disappears and browser hangs.

In Bughunter automation using marionette, two crash dumps are created. One is related to breakpad while the other is related to mozilla::detail::ConditionVariableImpl::wait(). You can see both in the attached log. Search for "Crash reason:".

It appears that an exception is thrown in mozilla::dom::ValueToPrimitive<bool,0>() which results in the call to wait which hangs.

Reproducible in Windows and Linux opt builds in Bughunter. Locally, I can reproduce the hang on debug builds on Fedora.

Crash reason:  EXCEPTION_BREAKPOINT
Crash address: 0x774c6c74
Process uptime: 21 seconds

Thread 0 (crashed)
 0  ntdll.dll + 0x46c74
    eip = 0x774c6c74   esp = 0x003fa3e8   ebp = 0x003fa430   ebx = 0x003fa444
    esi = 0x00000000   edi = 0x00000000   eax = 0x003fa4c0   ecx = 0x00f44420
    edx = 0x00000000   efl = 0x00000247
    Found by: given as instruction pointer in context
 1  kernel32.dll + 0x33135
    eip = 0x76b83135   esp = 0x003fa438   ebp = 0x003fa464
    Found by: previous frame's frame pointer
 2  mozglue.dll!mozilla::detail::ConditionVariableImpl::wait(mozilla::detail::MutexImpl &) [ConditionVariable_windows.cpp:c15e2f280729 : 58 + 0xa]
    eip = 0x6db5837f   esp = 0x003fa46c   ebp = 0x003fa47c
    Found by: previous frame's frame pointer
 3  xul.dll!mozilla::CondVar::Wait(unsigned int) [CondVar.h:c15e2f280729 : 68 + 0xb]
    eip = 0x5c5b9bbc   esp = 0x003fa484   ebp = 0x003fa494
    Found by: call frame info
 4  xul.dll!mozilla::ThreadEventQueue<mozilla::PrioritizedEventQueue<mozilla::LabeledEventQueue> >::GetEvent(bool,mozilla::EventPriority *) [ThreadEventQueue.cpp:c15e2f280729 : 138 + 0xa]
    eip = 0x5c5be347   esp = 0x003fa49c   ebp = 0x003fa4b4
    Found by: call frame info
 5  xul.dll!nsThread::ProcessNextEvent(bool,bool *) [nsThread.cpp:c15e2f280729 : 967 + 0x1e]
    eip = 0x5c5c02f2   esp = 0x003fa4bc   ebp = 0x003faa38
    Found by: call frame info
 6  xul.dll!js::InternalCallOrConstruct(JSContext *,JS::CallArgs const &,js::MaybeConstruct) [Interpreter.cpp:c15e2f280729 : 513 + 0xa]
    eip = 0x5e5dcee0   esp = 0x003fa52c   ebp = 0x003faa80
    Found by: stack scanning
 7  xul.dll!js::Call(JSContext *,JS::Handle<JS::Value>,JS::Handle<JS::Value>,js::AnyInvokeArgs const &,JS::MutableHandle<JS::Value>) [Interpreter.cpp:c15e2f280729 : 559 + 0x5]
    eip = 0x5e5d9b60   esp = 0x003fa5b0   ebp = 0x003faa98
    Found by: call frame info with scanning
 8  xul.dll!JS_CallFunctionValue(JSContext *,JS::Handle<JSObject *>,JS::Handle<JS::Value>,JS::HandleValueArray const &,JS::MutableHandle<JS::Value>) [jsapi.cpp:c15e2f280729 : 2907 + 0x12]
    eip = 0x5e2f0d55   esp = 0x003fa5e8   ebp = 0x003fa660
    Found by: call frame info with scanning
 9  xul.dll!mozilla::dom::AutoJSAPI::ReportException() [ScriptSettings.cpp:c15e2f280729 : 570 + 0x8]
    eip = 0x5d59666e   esp = 0x003fa5fc   ebp = 0x003fa660
    Found by: stack scanning
10  xul.dll!mozilla::dom::AutoJSAPI::ReportException() [ScriptSettings.cpp:c15e2f280729 : 635 + 0x3e]
    eip = 0x5d596959   esp = 0x003fa608   ebp = 0x003fa660
    Found by: stack scanning
11  xul.dll!mozilla::dom::ValueToPrimitive<bool,0>(JSContext *,JS::Handle<JS::Value>,bool *) [PrimitiveConversions.h:c15e2f280729 : 348 + 0xf]
    eip = 0x5c9fc8d7   esp = 0x003fa65c   ebp = 0x003fa620
    Found by: stack scanning

Comment 1

[:glob ✱]

The content of attachment 8907944 [details] has been deleted for the following reason:

At the request of the submitter

Comment 2

[Bob Clary [:bc] (inactive)]

Attachment: Windows Opt Log

I asked to have the url and the original attachment which contained it removed. This version of the log does not contain the url. If you are working on this bug contact me for the details.

Comment 3

[Bob Clary [:bc] (inactive)]

Attachment: Windows Opt Log with url

1. <https://www.rhbtradesmart.com/chartnexus/HTML5/HTML5_RHB_TRADE.html?code_base=https://www.rhbtradesmart.com/chartnexus/applet&client=rhbtrade&host_path=www.rhbtradesmart.com/chartnexus&s=3>

2. hang.

Comment 4

[Andrew Overholt [:overholt]]

I feel like Bill would want to see this given the stack in comment 0.

Comment 5

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Bob, can you give me some more details on how to reproduce this in Linux? I tried the URL in comment 3 with a Linux nightly. I got two alerts and hit "OK" for both. It just says "Initializing SGX..." and changes the number of periods forever. I'll try a Linux debug build when it finished building.

Comment 6

[Bob Clary [:bc] (inactive)]

On my Linux x86_64 build from this afternoon, I see the alert and once I click Ok the browser window disappears and the process appears to just sit there. I tried both with a local opt and debug builds.

With today's nightly build I get:

$ ~/bin/nightly/firefox/firefox -P lithium 'https://www.rhbtradesmart.com/chartnexus/HTML5/HTML5_RHB_TRADE.html?code_base=https://www.rhbtradesmart.com/chartnexus/applet&client=rhbtrade&host_path=www.rhbtradesmart.com/chartnexus&s=3'
JavaScript error: chrome://browser/content/browser.js, line 8291: TypeError: gBrowser.tabContainer is undefined
ExceptionHandler::GenerateDump cloned child 19176
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...

The generated dump has signature:
bp-c5a49419-b7ce-441e-ace4-f9dc10170918
[@ IPCError-browser | ShutDownKill ]

Comment 7

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Does it reproduce in a clean profile? I just tried with a debug build and it also works as expected (two alerts, then the page does some stuff forever).

Comment 8

[Bob Clary [:bc] (inactive)]

I tried locally with a clean profile with local opt and debug builds and *did not* reproduce the hang.

I could reproduce the behavior you describe when attempting to reproduce on Windows 7 32 and 64bit and when attempting it locally with a clean profile.

However, I resubmitted the url to Bughunter multiple times and got varying crashes related to nsThread::ProcessNextEvent but not with the mozilla::detail::ConditionVariableImpl::wait on the stack. These are always with a fresh profile though with the prefs set.

Windows 7 64bit opt:

js::jit::EnterBaselineMethod js::RunScript nsThread::HasPendingEvents nsBaseAppShell::DoProcessNextNativeEvent

Windows 7 32bit opt:

mozilla::widget::WinUtils::WaitForMessage nsAppShell::ProcessNextNativeEvent nsBaseAppShell::DoProcessNextNativeEvent nsBaseAppShell::OnProcessNextEvent nsThread::ProcessNextEvent

Fedora 64bit opt:

PollWrapper libglib-2.0.so.0.5200.3 libglib-2.0.so.0.5200.3 nsAppShell::ProcessNextNativeEvent nsBaseAppShell::DoProcessNextNativeEvent

Ubuntu 64bit opt:

PollWrapper libglib-2.0.so.0.4800.2 libglib-2.0.so.0.4800.2 nsAppShell::ProcessNextNativeEvent nsBaseAppShell::DoProcessNextNativeEvent

These are all using marionette to create the profile, start the browser, load the url and dismiss the alert. Perhaps it is a marionette issue. You can see the command used on Windows in attachment 8907949 [details].

Comment 9

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Thanks, Bob. The crucial preference is dom.allow_scripts_to_close_windows. When set to true, it allows the page to cause the browser to quit. When that happens, we get a shutdown hang since the web page is in the middle of a nested event loop for the alert() call. The stacks you're seeing are just our normal event loop. I'm pretty sure the ValueToPrimitive/exception reporting frames are bogus.

I would classify this under our general "we suck at shutting down" umbrella. We're trying to prioritize this for Q4. This particular STR won't be seen by users, but I suspect that something like this is possible.

Comment 10

[Bob Clary [:bc] (inactive)]

Thanks! That makes perfect sense. I totally missed that.

Comment 11

[Liz Henry (:lizzard)]

Too late for a fix for 57, but if we make headway here with nightly 59 we could still consider uplift to 58.

Comment 12

[Sylvestre Ledru [:Sylvestre]]

Closing because no crash reported since 12 weeks.