841892 - Java repeated Access Violations under Firefox

Status: RESOLVED INCOMPLETE

(Plugins Graveyard :: Java (Oracle), defect)

Description

[Lucius Chiaraviglio]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:18.0) Gecko/20100101 Firefox/18.0
Build ID: 20130201065344

Steps to reproduce:

1.  Start Firefox under windbg using the instructions at https://developer.mozilla.org/en-US/docs/How_to_get_a_stacktrace_with_WinDbg
2.  Navigate to a page that uses Java (http://www.java.com/en/download/testjava.jsp or go to http://www.nextbus.com, viewed the page for Massachusetts Bay Transportation Authority route 65, and then try to bring up the live map)
3.  Attempt to get a response from Firefox, even after leaving it overnight



Actual results:

Firefox freezes (but ONLY under windbg).  See attachment 712203 [details] originally filed under bug 290671 for a stack trace under windbg; this problem appeared when attempting to get a stack trace for bug 690774.



Expected results:

Firefox should not freeze; it should load the Java applet normally (possibly with a security warning message), and if the Java applet freezes (which does happen occasionally), it should be possible to close the offending tab and try again without needing to close Firefox as a whole (if Firefox is NOT running under windbg, this is the actual result).

Comment 1

[Matthias Versen [:Matti]]

Bugzilla is not the right place to ask for help with debugging.
You could ask on IRC or in the newsgroups.

Comment 2

[Lucius Chiaraviglio]

I wasn't asking for help with debugging.  In this bug report, Firefox exhibits a behavior that it shouldn't exhibit, that appears to be specific to loading a Java applet.  Whether the bug is in Firefox, Java, or windbg, I cannot tell, but clearly a bug exists.  This bug should be reopened.

Comment 3

[Matthias Versen [:Matti]]

The debugger halts Firefox if there is an exception and that's expected

Comment 4

[Lucius Chiaraviglio]

If Java is making an exception in Firefox, that's a bug.

Comment 5

[Matthias Versen [:Matti]]

https://bug290671.bugzilla.mozilla.org/attachment.cgi?id=712203
>0013fb1c 7c9402ed ntdll!DbgBreakPoint
and
>ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION}  Breakpoint  A breakpoint has been reached.

https://developer.mozilla.org/en-US/docs/How_to_get_a_stacktrace_with_WinDbg

>If Firefox fails to start, and you see lines of text followed by a command prompt in 
>the debugger, a "breakpoint" may have been triggered. If you are prompted for a 
>command but don't see an error about a crash, go back to the Debug menu and press Go.

Comment 6

[Lucius Chiaraviglio]

The issue isn't Firefox failing to start -- it starts and runs fine under windbg (with only the first Go being needed), UNTIL it attempts to load a Java applet (notice that the breakpoint is most of the way down the stacktrace).

Not sure if this is related, but in bug 690774 (unexpected quit at very long intervals without loading Java) it also apparently hits a breakpoint at nearly the end of the very long stacktrace (attachment 712535 [details] filed under that bug), after starting and running fine under windbg (again with only the initial Go being needed) for approximately 2 days.

So I wonder if the cause of BOTH bugs is that some debugging code was accidentally left enabled in Firefox?

Comment 7

[Matthias Versen [:Matti]]

Loading external resources can trigger a breakpoint AFAIK.
Just hit Go and it should continue. Such a breakpoint isn't triggered if you don't run the application under a debugger.

Comment 8

[Lucius Chiaraviglio]

For the loading of external resources to trigger a breakpoint sounds like a bug in windbg.  If that's the case, nothing we can do about it.

Comment 9

[Matthias Versen [:Matti]]

It should not be a problem since you can just hot debug->go and it will continue

Comment 10

[Lucius Chiaraviglio]

Attachment: Stacktrace of repeated exceptions (mostly Access Violation) when using Java

Okay, I did what you said, and Java repeatedly generated Access Violation breakpoints:  41 of them if I counted right, with almost half of these being just from attempting to start Java for the first time, and interspersed with 2 instances of Java hanging without generating a breakpoint or otherwise freezing Firefox (in which I had to close the offending tab and try again).  (This again is from nextnus.com --> MBTA bus route 65 --> Live Map.)  Access Violations frequently occurred when attempting to interact with the page (even just mousing over something that displays information, or checking a radio box), but also less frequently occurred with the program just sitting there, with even these less frequent Access Violations occurring more than once per minute.  Aside from this problem making debugging a real pain in certain situations, something is definitely broken between Firefox and Java.

Using Java Version 7 Update 13 (build 1.7.0_13-b20), updated approximately 1 week ago (can't check the exact date because for some reason my Java Control Panel's Update tab has disappeared again, but this is still the version listed on www.java.com as being current).

Comment 11

[Lucius Chiaraviglio]

Attachment: Similar to last attachment, but using Firefox 19.0, and in Safe Mode

Now that I got Firefox 19.0, I tried the same thing, this time using -safe-mode (entered as argument in windbg) because I stumbled upon bug 619349 and so I thought this might be a duplicate of it -- it probably isn't, because that bug depends upon extensions like AdBlock, etc.  This one is slightly different from the last stacktrace in that the second time that Java froze without freezing Firefox it had already loaded the applet and run the applet for a short time (with many access violations along the way); I was able to close the offending tab and try again, with the resulting access violations that followed.  Note the "BAD_INSTRUCTION_PTR_c0000005_jvm.dll!JVM_Clone" etc. in the analysis -- this is a real bug, although whether the bug is actually in Firefox or Java (VM) I cannot say.

Comment 12

[Andre Klapper]

Lucius: Does this still happen with a recent Firefox version? If so, which version are you using now?

Comment 13

[Lucius Chiaraviglio]

Sorry it took so long for me to get back to you.  Running Firefox 24.0 (as of this posting, this claims to be the latest stable release) on Windows XP SP3.

Comment 14

[Lucius Chiaraviglio]

Attachment: Stacktrace similar to original, but Firefox 24.0 and Java 7u45, under Windows 7 SP1

Since the Windows XP computer used above is also being replaced soon and the replacement is already here, I also tested the same thing on Firefox 24.0 (with Java 7u45) under Windows 7 Professional Service Pack 1, and get almost the same result, except that mousing over things on the NextBus page seems to cause access violations a lot less frequently than under Windows XP (still happens eventually; not yet sure if also panning the map is required to produce an access violation after the initial flood of them has passed).

By the way, https://developer.mozilla.org/en-US/docs/How_to_get_a_stacktrace_with_WinDbg probably needs an update, because Microsoft only offers 64bit WinDbg and tells you to use .effmach x86 to select 32bit mode; also, Windows 7 by default seems not to have a C:\temp directory (and WinDbg won't make one if you use the instructions in this page).

Due to the above (didn't figure it out until after I had already done everything), I had to manually copy and past the WinDbg log -- I think this has everything the automatically saved log file would have, but not 100% sure.

Comment 15

[Michelle Funches - QA]

@Reporter: Please confirm this is no longer an issue for you.
If it is, please state your current operating system, Firefox version and detailed test case.

Name 	Firefox
Version 	43.0.4
Build ID 	20160105164030
Mozilla/5.0 (Windows NT 5.1; rv:43.0) Gecko/20100101 Firefox/43.0

Comment 16

[Lucius Chiaraviglio]

Attachment: Stacktrace from Windbg run of Firefox 43.0.4 firefox-debug_36f8_2016-01-12_23-22-42-121.log

Stacktrace from Windbg run of Firefox 43.0.4 attached.

On the one hand, Firefox 43.0.x (and a few versions before) now works properly when not being debugged with pages containing Java (although the NextBus Java page linked above is no longer available, the Oracle Java test page works), and bug 690774 (unexpected quit at very long intervals without loading Java) does not occur under Windows 7 SP1 Professional 64-bit edition (can no longer test on Windows XP -- that seemed to be a Windows XP-specific bug).

On the other hand, Java (using the Oracle Java test page linked above) still generates several exceptions in Firefox when it is running under Windbg.  After Oracle's Java test completed, also got some more exceptions from clicking the button "Firefox seems slow... Fix it" (can't remember exact wording).  Attached log from Windbg run.

Comment 17

[Benjamin Smedberg]

Starting in Firefox 44, Java always runs out-of-process (using plugin-container.exe instead of firefox.exe). Without more stack, I couldn't really tell you whether the access violation is in Firefox code or Java code, but from prior experience almost all crashes have been in Java code. In which case you would need to report this to Oracle, not here.

I'm going to resolve this INCOMPLETE, but in Firefox 44+ if you discover that there is an access violation with a stack in Firefox code, please reopen and NEEDINFO me and I'll have another look.