Closed
Bug 555699
Opened 15 years ago
Closed 9 years ago
OOPP: Java's Signature Warning window is not detected by hang detector [@ hang | ntdll.dll@0x1f861 ]
Categories
(Core Graveyard :: Plug-ins, defect)
Tracking
(status1.9.2 unaffected, status1.9.1 unaffected)
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
status1.9.2 | --- | unaffected |
status1.9.1 | --- | unaffected |
People
(Reporter: andreasjunghw, Unassigned)
References
()
Details
(Whiteboard: [bugday0601])
Attachments
(2 obsolete files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a4pre) Gecko/20100328 Minefield/3.7a4pre (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a4pre) Gecko/20100328 Minefield/3.7a4pre
If you open the provided URL the Java Plug-in will prompt you with a signature warning. If you ignore this warning by switching to another application etc. it will crash the Java Plug-in.
If you choose send crash report it will actually create two crash reports?!
Crash reports:
http://crash-stats.mozilla.com/report/index/f4b7cfff-1254-459b-b085-082402100329
http://crash-stats.mozilla.com/report/index/7de93a9c-cc7f-4730-b2d8-dde552100329
http://crash-stats.mozilla.com/report/index/d45f4bea-b636-4aa1-b489-3f53d2100329
http://crash-stats.mozilla.com/report/index/180064d5-ce14-4fa9-8bdf-2b2482100329
Reproducible: Always
Steps to Reproduce:
1.Open provided URL
2.Switch to another application
3.(wait a few seconds)
Actual Results:
The Java plug-in crashes.
Expected Results:
The Java plug-in doesn't crash.
Sun Java
java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Client VM (build 14.3-b01, mixed mode, sharing)
two reports mean that you've deadlocked, so there's one for firefox and one for the plugin host (of java)
firefox:
mozilla::plugins::PluginModuleParent::ShouldContinueFromReplyTimeout dom/plugins/PluginModuleParent.cpp:224
mozilla::ipc::SyncChannel::ShouldContinueFromTimeout ipc/glue/SyncChannel.cpp:258
mozilla::ipc::RPCChannel::Call ipc/glue/RPCChannel.cpp:214
mozilla::plugins::PPluginInstanceParent::CallNPP_GetValue_NPPVpluginScriptableNPObject obj-firefox/ipc/ipdl/PPluginInstanceParent.cpp:242
mozilla::plugins::PluginInstanceParent::NPP_GetValue dom/plugins/PluginInstanceParent.cpp:527
mozilla::plugins::PluginModuleParent::NPP_GetValue dom/plugins/PluginModuleParent.cpp:504
nsNPAPIPluginInstance::GetValueFromPlugin modules/plugin/base/src/nsNPAPIPluginInstance.cpp:1407
nsNPAPIPluginInstance::GetJSObject modules/plugin/base/src/nsNPAPIPluginInstance.cpp:1495
nsHTMLPluginObjElementSH::GetPluginJSObject dom/base/nsDOMClassInfo.cpp:9624
nsHTMLPluginObjElementSH::SetupProtoChain dom/base/nsDOMClassInfo.cpp:9359
nsObjectFrame::NotifyContentObjectWrapper layout/generic/nsObjectFrame.cpp:2370
nsObjectFrame::TryNotifyContentObjectWrapper layout/generic/nsObjectFrame.cpp:2120
nsObjectFrame::Instantiate layout/generic/nsObjectFrame.cpp:2093
plugin:
GetQueuedCompletionStatus
base::MessagePumpForIO::GetIOItem ipc/chromium/src/base/message_pump_win.cc:520
base::MessagePumpForIO::WaitForIOCompletion ipc/chromium/src/base/message_pump_win.cc:491
base::MessagePumpForIO::WaitForWork ipc/chromium/src/base/message_pump_win.cc:484
base::MessagePumpForIO::DoRunLoop ipc/chromium/src/base/message_pump_win.cc:469
base::MessagePumpWin::RunWithDispatcher ipc/chromium/src/base/message_pump_win.cc:52
base::MessagePumpWin::Run ipc/chromium/src/base/message_pump_win.h:78
MessageLoop::RunInternal ipc/chromium/src/base/message_loop.cc:216
MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:199
Summary: Ignoring Java's Signature Warning (e.g. switching to another application) crashes Java → Ignoring Java's Signature Warning (e.g. switching to another application) results in deadlock
Comment 2•15 years ago
|
||
This is the hang detector kicking in. Apparently the code that we use to detect when the plugin spins an event loop (such as displaying a modal dialog) isn't detecting the Java signature dialog. After a 10 second timeout we collect the stack minidump of both the firefox and plugin process, then terminate the plugin process.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Ignoring Java's Signature Warning (e.g. switching to another application) results in deadlock → OOPP: Java's Signature Warning not detected by hang detector
Comment 3•15 years ago
|
||
dupe of bug 549930?
Comment 4•15 years ago
|
||
No. That bug is about XStandard, and probably has a different root cause.
Comment 6•15 years ago
|
||
The signature for this has changed and the stack for both the parent and plugin is completely different:
firefox:
Signature hang | mozilla::plugins::PPluginInstanceParent::CallUpdateWindow()
UUID 213bc143-74ae-4333-a54a-16a812100503
plugin:
Signature hang | KiFastSystemCallRet
UUID 6c9bd420-3837-4cac-903d-9ea402100503
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100502
Minefield/3.7a5pre ( .NET CLR 3.5.30729) ID:20100502040440
Comment 7•15 years ago
|
||
Sorry, I should mention that the original signature mozilla::plugins::PPluginInstanceParent::CallNPP_GetValue_NPPVpluginScriptableNPObject(mozilla::plugins::PPluginScriptableObjectParent**, short*)
does still persist in crash reports. Both are low volume (9 in the last week)
This might be related,
1.6.0_17 works just, but 1.6.0_18 (and higher) always crashes - warning dialog unresponsive.
Steps to reproduce,
1. Find website that uses Java and Java prompts a security warning
2. Firefox will get stuck for ~20 seconds
3. Then the Java(TM) security dialog (Run, Cancel) will pop up.
4. This dialog will be unresponsive to input.
5. ~8 seconds later, dialog goes away, Firefox reports Java Plug-in Crashed.
Reproducible: Always.
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100506 Minefield/3.7a5pre
HP Mini 311, Windows 7 x86_32
Updated•15 years ago
|
blocking2.0: --- → beta1+
Comment 10•15 years ago
|
||
My current thought here is that the Java plugin ought not to be blocking the host (Firefox) on the signature verification dialog. That ought to be presented as an asynchronous dialog so that the browser can continue to function normally (and the user can switch tabs etc) while the signature dialog is presented.
Comment 11•15 years ago
|
||
I've tried FF 3.6.3 with JRE 6u18 and couldn't reproduce the problem.
Does it only reproduce with FF 3.7a4pre?
Comment 12•15 years ago
|
||
You need to be running the plugin out-of-process, so use either FF 3.6.4 beta or FF 3.7pre.
Comment 13•15 years ago
|
||
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1) Gecko/20100208 MozillaDeveloperPreview/3.7a1
It works fine on 3.7a1 with JRE 6u20. couldn't reproduce the problem
Build broken : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a2pre) Gecko/20100209 Minefield/3.7a2pre
Firefox crashes if i click the cancel button on the Java Security Dialog box and close the browser.
Crash reports:
http://crash-stats.mozilla.com/report/index/bp-df7cf9d9-f57f-4ef3-ad9f-f17ad2100513
http://crash-stats.mozilla.com/report/index/bp-afe6e24e-e763-4c98-a018-686602100513
Comment 14•15 years ago
|
||
(In reply to comment #13)
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1) Gecko/20100208
MozillaDeveloperPreview/3.7a1 is not a recent enough build to be testing this bug against.
I still see this in the trunk, Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a5pre) Gecko/20100601 Minefield/3.7a5pre. The hang that was detected on my system is Bug 564298, ID: b2076f61-3e9c-4306-82e9-e329b2100601 Signature: hang | mozilla::plugins::PPluginInstanceParent::CallUpdateWindow()
Updated•15 years ago
|
Whiteboard: [bugday0601]
Comment 15•15 years ago
|
||
Build worked :
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1) Gecko/20100208 MozillaDeveloperPreview/3.7a1
Build broken :
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a2pre) Gecko/20100209 Minefield/3.7a2pre
Pushlog :
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=43e818c28059&tochange=19dbabe331ad
Comment 16•15 years ago
|
||
The cause of this problem is well-understood, we don't need a regression range. I believe that this is a bug in the Java plugin and should be addressed by them, not by Firefox, and have contacted Sun/Oracle engineers about it. I'm going to mark it blocking-final just to make sure we have some resolution.
blocking2.0: beta1+ → final+
Comment 17•15 years ago
|
||
With OOPP Firefox 3.7a5pre, I noticed the java plugin module (npjp2.dll) was loaded by both firefox.exe and plugin-container.exe processes.
If the plugin is running within the plugin-container.exe process, why is the plugin module being loaded by the firefox.exe process?
Which process does the plugin window belong to?
When a modal dialog such as a security dialog is being displayed, the java plugin sets up windows hook to filter out mouse and focus/activation events. It also starts a message pump on the thread which instantiates the plugin. The message pump is using the following event mask:
PM_REMOVE | PM_QS_PAINT | PM_QS_POSTMESSAGE | PM_QS_SENDMESSAGE
When the dialog is up, I wasn't seeing the browser tab window being repainted when the dialog was moved on top of the browser window. So we maybe pumping events in the wrong thread.
I'm not sure what java plugin should do to fix this problem currently and open to suggestions. Many customers expect the security dialog to be modal. Displaying the dialog in a different thread and making it non-modal isn't a good solution.
Comment 18•15 years ago
|
||
The plugin DLL is being loaded in the Firefox process so that we can extract the MIME type and description information on it. We don't run plugin instances in the Firefox process.
The plugin window belongs to the plugin-runtime process.
When a plugin (Java/Flash) presents a native modal dialog, we detect this using a windows hook and spin the Firefox event loop while the modal dialog is displayed. Is it possible that you have installed your windows hook incorrectly and it is not calling ::CallNextHookEx at the end of its function. That would prevent it from chaining to our hook.
Comment 19•15 years ago
|
||
Our windows hook calls the CallNextHookEx before returning.
We're using SetWindowsHookEx to setup the windows hook such as:
SetWindowsHookEx(WH_MOUSE, &mouseHookProc, 0, thread);
For the message pump, we're passing in NULL as the window handle. So it should be retrieving messages for all windows associated with the current thread.
As for the painting problem mentioned in my previous comment #17, I noticed that the parent window of the plugin window belongs to a different process. Chorme is also running plugin in a separate process and I'm not seeing the painting issue or this issue (plugin process got terminated).
How does the FF hang detector determines the plugin process is hung?
When is FF 3.7 going to be released?
Comment 20•15 years ago
|
||
The plugin is hung when a NPAPI call doesn't return for 10 seconds and our hook hasn't detected that you've spun a nested modal event loop. Firefox 4 is scheduled to go to beta in 2 weeks and final in October.
status1.9.1:
--- → unaffected
status1.9.2:
--- → unaffected
![]() |
||
Comment 21•15 years ago
|
||
I think the problem here is that the security dialog isn't a dialog, it's a popup window. We set a message filter hook for dialogs, which wouldn't pick up the display of this window. A little testing will confirm this. We might have to switch our filter hook out with a more generic message hook.
Updated•15 years ago
|
Assignee: nobody → jmathies
Comment 22•15 years ago
|
||
Is bug 577808 a duplicate of this one?
Comment 23•15 years ago
|
||
Also reproducible with Firefox 4 beta 2
Summary: OOPP: Java's Signature Warning not detected by hang detector → OOPP: Java's Signature Warning window is not detected by hang detector
![]() |
||
Comment 26•15 years ago
|
||
Is there some way to reset this dialog? I clicked cancel, and now I can't get it to show again.
![]() |
||
Comment 27•15 years ago
|
||
oop, ok, now it's back.
Comment 28•15 years ago
|
||
Now, the signatures are not the same :
Signature hang | ntdll.dll@0x1f861
UUID 361234da-01b1-4942-8295-2e5e22100902
Signature hang | mozilla::plugins::PPluginInstanceParent::CallNPP_GetValue_NPPVpluginScriptableNPObject(mozilla::plugins::PPluginScriptableObjectParent**, short*)
UUID 37982283-2301-4dcf-98d5-291f22100902
Assignee: jmathies → nobody
Component: Plug-ins → Java (Oracle)
Product: Core → Plugins
QA Contact: plugins → oracle-java
Summary: OOPP: Java's Signature Warning window is not detected by hang detector → OOPP: Java's Signature Warning window is not detected by hang detector [@ hang | ntdll.dll@0x1f861 ]
Version: unspecified → 6.x
Comment 30•15 years ago
|
||
If they are different, could mean they are different bugs.
Comment 31•15 years ago
|
||
The hang can happen at any number of different call sites; the signature isn't going to be deterministic.
Comment 32•15 years ago
|
||
The bug is in the java plugin (see comment 16).
The java plugin signature has not changed :
3 npjp2.dll npjp2.dll@0x149e
Only the propagation of java plugin crash can be different :
+ hang | ntdll.dll@0x1f861 :
* Now,, with the URL of this bug
* bug 577808 which is a dupe
* Now, with the URL of bug 588326
* bug 591328 which is a dupe
+ hang | KiFastSystemCallRet :
* this bug
* bug 588326 which is a dupe
May be [@ hang | KiFastSystemCallRet ] and [@ npjp2.dll@0x149e ] must be added to the bug title ?
Comment 33•15 years ago
|
||
No, please don't. KiFastSystemCallRet is a generic signature that could just about any bug, and we really don't need more information.
![]() |
||
Comment 34•15 years ago
|
||
Good loss of dialog interaction test case:
https://as.photoprintit.de/web/84004066/startClient.do?client=java&type=print
Updated•15 years ago
|
Assignee: nobody → jmathies
Component: Java (Oracle) → Plug-ins
Product: Plugins → Core
QA Contact: oracle-java → plugins
Version: 6.x → Trunk
![]() |
||
Comment 37•15 years ago
|
||
(In reply to comment #17)
> With OOPP Firefox 3.7a5pre, I noticed the java plugin module (npjp2.dll) was
> loaded by both firefox.exe and plugin-container.exe processes.
>
> If the plugin is running within the plugin-container.exe process, why is the
> plugin module being loaded by the firefox.exe process?
>
> Which process does the plugin window belong to?
>
> When a modal dialog such as a security dialog is being displayed, the java
> plugin sets up windows hook to filter out mouse and focus/activation events. It
> also starts a message pump on the thread which instantiates the plugin. The
> message pump is using the following event mask:
> PM_REMOVE | PM_QS_PAINT | PM_QS_POSTMESSAGE | PM_QS_SENDMESSAGE
>
> When the dialog is up, I wasn't seeing the browser tab window being repainted
> when the dialog was moved on top of the browser window. So we maybe pumping
> events in the wrong thread.
>
> I'm not sure what java plugin should do to fix this problem currently and open
> to suggestions. Many customers expect the security dialog to be modal.
> Displaying the dialog in a different thread and making it non-modal isn't a
> good solution.
Calvin, is WM_CREATE one of the events your hook filters? (I believe it is based on the fact that our hook does not receive it for your dialog.) But thought I'd ask for confirmation.
This makes it very hard for us to detect these window.
![]() |
||
Comment 38•15 years ago
|
||
Actually, we don't receive *any* events in our hook for this window. The only events we get are for our plugin window.
Without something to trigger off of I'm going to have a hard time fixing this.
![]() |
||
Comment 39•15 years ago
|
||
So it appears that the security warning is being created by a 3rd process (java.exe) with it's parent set to the browser. The deadlock happens wen the parent sends messages to the child. The child thread is deadlocked waiting for the 3rd java process to return control. (which presumably is waiting on the parent browser to respond to windowing events.)
![]() |
||
Comment 40•15 years ago
|
||
(In reply to comment #39)
> So it appears that the security warning is being created by a 3rd process
> (java.exe) with it's parent set to the browser. The deadlock happens wen the
> parent sends messages to the child. The child thread is deadlocked waiting for
> the 3rd java process to return control. (which presumably is waiting on the
> parent browser to respond to windowing events.)
To follow up, so the reason why we lock up is due to the fact that the ui is created in the 3rd process. Hence we are unable to detect it in the child plugin process, so we don't spin our spin loop in parent. So all of our measures to prevent this don't kick in.
![]() |
||
Updated•15 years ago
|
blocking2.0: betaN+ → ---
![]() |
||
Comment 42•15 years ago
|
||
![]() |
||
Comment 43•15 years ago
|
||
![]() |
||
Comment 44•15 years ago
|
||
Comment on attachment 483517 [details] [diff] [review]
move quirks to module v.1
not critical work, just some good cleanup on quirks mode.
Attachment #483517 -
Flags: review?(benjamin)
![]() |
||
Updated•15 years ago
|
Attachment #483518 -
Flags: review?(benjamin)
![]() |
||
Comment 46•14 years ago
|
||
Comment on attachment 483517 [details] [diff] [review]
move quirks to module v.1
these landed in another bug.
Attachment #483517 -
Attachment is obsolete: true
Attachment #483517 -
Flags: review?(benjamin)
![]() |
||
Updated•14 years ago
|
Attachment #483518 -
Attachment is obsolete: true
Attachment #483518 -
Flags: review?(benjamin)
Comment 47•14 years ago
|
||
status1.9.2: unaffected ,it has the same problem, see http://crash-stats.mozilla.com/report/pending/00a688df-1304-4953-8e96-6946b2101230 ,this is not the first crash report i`m sending..
Comment 48•14 years ago
|
||
Ah i think it's different from AdBlock Plus bug..
![]() |
||
Comment 49•14 years ago
|
||
Fixed by bug 603417, but technically still a bug in oopp, so I'll leave this open.
Assignee: jmathies → nobody
Reporter | ||
Comment 50•9 years ago
|
||
Afaict since bug 874167 was fixed the java plugin is run out-of-process again.
Testing with Firefox 44.0 and Java 8 U71 and different java applets that cause signature warning dialogs (like the one linked in the bug report URL field) or cause a warning because they request unsandboxed execution (like the check java version applet on java.com) I didn't get any hangs, crashes or other problems, therefore I'm resolving this bug as worksforme.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
Updated•3 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•