Closed Bug 847819 Opened 11 years ago Closed 7 years ago

crash in nsJSObjWrapper::NP_HasMethod @ JSAutoCompartment::JSAutoCompartment caused by a Java Applet using LiveConnect

Categories

(Core Graveyard :: Plug-ins, defect, P3)

Product:
Core Graveyard
Component:
Plug-ins
Version:
19 Branch
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: wdick, Unassigned)

References

(
URL
)

Details

(Keywords: crash, reproducible)

Crash Data

Attachments

(2 files, 1 obsolete file)

windbg trace
659.88 KB, text/plain
Details
hs_err_pid121420.log
25.59 KB, text/plain
Details
Attached file hs_err_pid43732.log (obsolete) — 
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.152 Safari/537.22

Steps to reproduce:

Hello,
when I load our Java applet and hit the "Reload current page" or "Back" button, 
then Firefox crashes with an EXCEPTION_ACCESS_VIOLATION. See the attached HotSpot Error log.
The crash happens after the applet destroy phase.

Our Java applet uses JNA to load the native PC/SC library. The crash happens only, 
if the applet locates a smartcard reader. So, to reproduce the crash, you have to have a connected smartcard reader.

I would be happy to fix any problems, which lead to the crash, in our applet, but I have no idea what causes the crash.

Firefox doesn't crash:
- If a card reader is connected, but LiveConnect is not used.
- If LiveConnect is used, but no card reader is found.

I tested with the Firefox 19 and a nightly build 22.0a1 (2013-02-26) and 22.0a1 (2013-03-04) on Windows 7.

I managed to create a crash report under my Debian system: 
https://crash-stats.mozilla.com/report/index/bp-ac969065-d6da-4803-b46a-6a8192130305
Severity: normal → critical
Status: UNCONFIRMED → NEW
Crash Signature: [@ JSAutoCompartment::JSAutoCompartment ]
Component: Untriaged → Plug-ins
Ever confirmed: true
Keywords: crash
OS: Windows 7 → Linux
Product: Firefox → Core
Hardware: x86_64 → x86
Summary: Memory Access Violation caused by a Java Applet using LiveConnect → crash in nsJSObjWrapper::NP_HasMethod @ JSAutoCompartment::JSAutoCompartment caused by a Java Applet using LiveConnect
Hi,
I put the applet, which crashes Firefox, on the following site:
http://cloudsuite.intarsys.de/cloudsuite-snippets/jsui_basic_signature_do.xhtml

Greetings,
Waldemar
Looks like either the JSContext or the JSObject passed to the AutoCompartment are invalid here:
http://hg.mozilla.org/releases/mozilla-release/diff/0d61ae018d9f/dom/plugins/base/nsJSNPRuntime.cpp

... which results in a crash in/before the JSAutoCompartment ctor when trying to get the compartment:
http://hg.mozilla.org/releases/mozilla-release/diff/ef35ba222ac8/js/src/gc/Heap.h
Waldemar, do you know if this previously worked, i.e. if it's a regression in Java or Firefox?
Flags: needinfo?(wdick)
Hi,
i tried Firefox 3.0, 3.6 and 17 ESR on Windows 7.
Firefox 3.0 crashes, when the applet is loaded.
Firefox 3.6 and 17 crash, when the page is reloaded.

I will try to get a crash report on Linux.
Flags: needinfo?(wdick)
On my Debian 7 system I tried:
- Firefox 3.6 -> page reload doesn't crash
- Firefox 12.0 -> page reload doesn't crash
- Firefox 15.0 -> page reload doesn't crash
- Firefox 16.0 -> page reload doesn't crash
- Firefox 17.0 -> page reload doesn't crash

- Firefox 18.0 -> https://crash-stats.mozilla.com/report/index/bp-c284e9cc-d308-4a5e-abbe-196362130305

- Firefox 19.0 (again)-> https://crash-stats.mozilla.com/report/index/bp-ce9c0235-71d0-466a-a408-44a812130305

On Windows 7 Firefox crashed on every page reload. On Debian I have to try a couple of time, before it crashes.
Thank you for the info. 
It sounds like you don't have any crash ids at all for this on Windows in about:crashes?
Priority: -- → P2
(In reply to Georg Fritzsche [:gfritzsche] from comment #6)
> It sounds like you don't have any crash ids at all for this on Windows in
> about:crashes?

No, the crashes are not reported on Windows.

If it helps, I can try to record a trace with WinDbg.
I can't produce on Windows 7 x64 over a few page reloads with:
* Fx 18.0.2, 19, Nightly
* the current Java 7U17 (10.7.2.2) and 7U15

Stacks with Mozilla symbols[1] would be great if you could provide them.

[1] https://developer.mozilla.org/en-US/docs/Using_the_Mozilla_symbol_server
Attached file windbg trace — 
This is a windbg trace. I don't know if it is useful at all, because some symbols are missing and I maybe missed the right exceptin break point.
(In reply to Georg Fritzsche [:gfritzsche] from comment #9)
> I can't produce on Windows 7 x64 over a few page reloads with:
> * Fx 18.0.2, 19, Nightly
> * the current Java 7U17 (10.7.2.2) and 7U15

Do you have a smartcard reader connected? It doesn't crash on you, when you it "Reload" after the message "Please insert a smartcard into the card reader." is shown?

If you don't have smartcard reader, I can send you one.
Thanks for the trace. I'm not very familiar with the WinDbg out (so i'd appreciate another look from someone else), but the exception analys says it's a crash (access violation) in java.exe:
> 3:088> |* !analyze -v -f
[...]
> PROCESS_NAME:  java.exe
[...]
>    ExceptionCode: c0000005 (Access violation)

... so it would be a separate (Oracle) issue.
Or is Firefox still crashing afterwards? I don't see any stack related to us in the trace.
(In reply to Georg Fritzsche [:gfritzsche] from comment #12)
> but the exception analys says
> it's a crash (access violation) in java.exe:

Background: ".childdbg 1" tells WinDbg to attach to child processes and java.exe is launched as a child process by the Java plugin - that's why this is caught in this trace.
(In reply to Waldemar Dick from comment #11)
> Do you have a smartcard reader connected? It doesn't crash on you, when you
> it "Reload" after the message "Please insert a smartcard into the card
> reader." is shown?

I don't have a smartcard reader and i don't see such a message on the linked site:
http://cloudsuite.intarsys.de/cloudsuite-snippets/jsui_basic_signature_do.xhtml

But if this crash is limited to java.exe the Windows issue should be filed with Oracle anyway.
bsmedberg, per comment 12 the windows crash is an Oracle bug, right?
(With the original report being a Linux crash in Fx)
Flags: needinfo?(benjamin)
(In reply to Waldemar Dick from comment #0)
> Our Java applet uses JNA to load the native PC/SC library. The crash happens
> only, 
> if the applet locates a smartcard reader. So, to reproduce the crash, you
> have to have a connected smartcard reader.

Sorry Waldemar, i initially over-read that part. You don't think there is any chance you could reproduce this without a smartcard reader?

Otherwise it's much harder to work on this with different testers, contributors, etc.
Flags: needinfo?(wdick)
Priority: P2 → P3
Also, does this reproduce on Firefox Aurora? [1]
We are making Java run out-of-process again on non-Windows platform, so it's possible that it is something that's not happening under those circumstances.


[1] http://www.mozilla.org/en-US/firefox/channel/#aurora
Correct, the Windows crash is 1) not this bug 2) an Oracle bug that we don't want to track in Mozilla bugzilla.

The original bug here is different: it may be an Java bug or ours, and if it's a Java bug it still might be possible to defend against it.
Flags: needinfo?(benjamin)
Hi,

(In reply to Georg Fritzsche [:gfritzsche] [away Mar 8 - Mar 17] from comment #16)
> Otherwise it's much harder to work on this with different testers,
> contributors, etc.

I know and I will try to reproduce it without a smartcard reader.



(In reply to Georg Fritzsche [:gfritzsche] [away Mar 8 - Mar 17] from comment #17)
> Also, does this reproduce on Firefox Aurora? [1]
> We are making Java run out-of-process again on non-Windows platform, so it's
> possible that it is something that's not happening under those circumstances.

I will check Firefox Aurora in the next hour.



(In reply to Benjamin Smedberg  [:bsmedberg] from comment #18)
> Correct, the Windows crash is 1) not this bug 2) an Oracle bug that we don't
> want to track in Mozilla bugzilla.
> 
> The original bug here is different: it may be an Java bug or ours, and if
> it's a Java bug it still might be possible to defend against it.

Firefox behaves differently, when WinDbg is connected. 

Can I help you any other way? Something like remote debugging on a my machine?
Flags: needinfo?(wdick)
(In reply to Waldemar Dick from comment #19)
> I know and I will try to reproduce it without a smartcard reader.
[...]
> (In reply to Georg Fritzsche [:gfritzsche] [away Mar 8 - Mar 17] from
> comment #17)
> > Also, does this reproduce on Firefox Aurora? [1]
> > We are making Java run out-of-process again on non-Windows platform, so it's
> > possible that it is something that's not happening under those circumstances.
> 
> I will check Firefox Aurora in the next hour.

Did you have any luck on those two things?

> Firefox behaves differently, when WinDbg is connected. 

So Fx is crashing from this on Windows too? Can you catch a stack for that if you don't attach to child processes (i.e. leave out ".childdbg 1")?
(In reply to Georg Fritzsche [:gfritzsche] [away Mar 8 - Mar 17] from comment #20)

> > > Also, does this reproduce on Firefox Aurora? [1]
> > I will check Firefox Aurora in the next hour.
> 
> Did you have any luck on those two things?

No. Firefox Aurora crashed too and I didn't get a Firefox crash-report.


> > Firefox behaves differently, when WinDbg is connected. 
> 
> So Fx is crashing from this on Windows too? Can you catch a stack for that
> if you don't attach to child processes (i.e. leave out ".childdbg 1")?

I will try.
Hello,
it took a while, but now I can reproduce the bug without a smartcard reader.

To reproduce the bug, go to: http://cloudsuite.intarsys.de/cloudsuite-snippets/firefox-crash.xhtml

You have to enable Java to load the Java Applet. 
I mocked the PC/SC events and signed my code changes with a self signed certificate, so you have to trust a insecure certificate. If this is a problem, I can sign the code with our corporate certificate, but this will take some time.

Wait until you see the message "Please insert a smartcard into the card reader." and then press the Reload button.
Firefox should crash then.

Hope this helps.

Greetings
Waldemar Dick
I can reproduce with the STR in comment 22 on Windows but there's no Crash Reporter.
URL: http://cloudsuite.intarsys.de/cloudsu... → http://cloudsuite.intarsys.de/cloudsu...
Keywords: reproducible
OS: Linux → All
Hardware: x86 → All
(In reply to Waldemar Dick from comment #22)
> Hope this helps.

Definitely, thank you.
Depends on: 885443
I can't reproduce in Nightly.
Can you still reproduce? What is your crash ID now?
Flags: needinfo?(wdick)
(In reply to Scoobidiver from comment #25)
> I can't reproduce in Nightly.
> Can you still reproduce? What is your crash ID now?

Hi, sorry for the late answer.

I tried Aurora 24.0a2 (2013-08-04) and it still crashes withou a crash ID.
I will attach the jvm stack dump.
Flags: needinfo?(wdick)
Attached file hs_err_pid121420.log — 

        Attachment #721101 -
        Attachment is obsolete: true

    
    

    
  
The demo page http://cloudsuite.intarsys.de/cloudsuite-snippets/firefox-crash.xhtml won't start the Java applet right now.
I will fix it this week.

    
    

    
  
I'm marking this bug as WONTFIX per bug #1269807.

For more information see - https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX

    
  
Product: Core → Core Graveyard

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: