Firefox 3.6a1, 3.5.3, 3.5.4, 3.0.14, 3.0.15, and Camino 2.0 (Gecko 1.9.2, 1.9.1, and 1.9.0) are showing a (large, depending on penetration of the version) number of crashes due to uncaught exceptions related to Java on 10.5 and 10.6. These all have JEP 0.9.7.2, so (for the 10.6 crashes) these are not the "old JEP is incompatible with 10.6" crash (bug 512834). It's also unlikely that these are all people hacking their Java install on 10.6 to add Java 1.5 back, since a) about half of the crashes are on 10.5 and b} the comments, where they exist, don't sound like they're coming from the sort of people who have the skill to hack their Java install. It's currently a topcrash for Camino 2, in the Mac top 100 for 3.5.3 and 3.5.4, and in the Mac top 5 for 3.6b1 (there are assorted other binary add-ons that also trigger crashes due to uncaught exceptions, but the vast majority of the reports are JEP).
Not all of these are related to Java, but many of them appear to be so. http://people.mozilla.org/~dbaron/crash-stats/20090929-interesting-modules For a long time I've been seeing a trickle of reports of crashes with 'registerNatives' in their stacks. I've never had enough information to do anything about them. Have these crashes started to increase in frequency ... or is it just that our crash reporting is getting better? (Needless to say, ___TERMINATING_DUE_TO_UNCAUGHT_EXCEPTION___ in a stack is meaningless by itself. Many different kinds of crashes may have this at the top of the stack.)
Interestingly, none of these crashes appear to be older than 2009-09-01.
I suspect this means Breakpad wasn't keeping track of them before then.
(In reply to comment #2) > Interestingly, none of these crashes appear to be older than 2009-09-01. (In reply to comment #3) > I suspect this means Breakpad wasn't keeping track of them before then. Could be. Or we could be calling them something different now. Or they're just so few and far between that they're hard to see. Or it's hard to search crash-stats so it's hard to know. Also you should use this updated interesting-modules analysis: http://people.mozilla.com/crash_analysis/
The one thing we can be sure of is these crashes didn't start happening on 2009-09-01 :-)
We can also be sure they didn't start happening much more frequently on that date.
> We can also be sure they didn't start happening much more frequently > on that date. This may be wrong. The vast majority of these crashes happen on OS X 10.6 or 10.6.1, and 10.6 was released on 2009-08-28. The Crash Stats site (http://crash-stats.mozilla.com/) doesn't provide a way to search crashes by OS version. So I load a bunch of crash stacks in a single page and try sorting them by OS version. But the sorter will only sort the top N results. So I try to limit the number of results to less than 100 by other means. One way to do this is to search over the span of an hour (or perhaps a day), instead of a week (which is the default). You change the "occurs before" field to get results from different times in the past. Setting "occurs before" to "09/10/2009" and "within the last" to "1 hours" returns 15 instances of this crash. Of these 1 is on OS X 10.5.8 and all the others are on OS X 10.6.0. On this date the number of SnowLeopard users must still have been very small compared to the number of Leopard users.
Silly me -- I forgot that when you load a Java applet on SnowLeopard with old versions of the JEP (older than 0.9.7), you get a crash at ___TERMINATING_DUE_TO_UNCAUGHT_EXCEPTION___ with registerNatives also on the stack. For example see bug 512834 comment #0. The first versions of Firefox that bundled a JEP which doesn't crash on SnowLeopard are 3.5 and 3.0.12. So we can assume that all instances of this crash (with registerNatives in the stack, on SnowLeopard) in FF 3.0.11 or below are caused by using a version of the JEP that doesn't support SnowLeopard. If, at http://crash-stats.mozilla.com/, I limit my search to versions of FF that bundle a SnowLeopard-compatible JEP, this bug's crash falls to #90 in the OS X top-crasher list (from #4 if I don't do this). As for Camino, crash-stats seems only to track crashes in Camino 2.0.X. As far as I know, all versions of Camino 2.0 bundle a SnowLeopard-compatible JEP, so none of the Camino 2.0 crashes is due to SnowLeopard incompatibility. And though I'm sure the number of these crashes in Camino 1.6.X on SnowLeopard (all of which are due to the compatibility problem) is far higher, this bug's crash is #9 on the Camino 2.0 topcrash list (with 5 crashes in the last week). So clearly this bug isn't an urgent issue on Firefox. But it may be somewhat urgent on Camino 2.0. Finally, a very simple workaround occurs to me: If I wrapped the call to registerNatives in a try/catch block, these crashes would (presumably) no longer happen. The applet would still fail to load. But if I printed the exception message to stdout, I might actually stand a chance to find out enough about the "other" registerNatives problems to fix them. And in any case failure with an error message is better than a crash. I'll do this in the next JEP release.
(In reply to comment #1) > (Needless to say, ___TERMINATING_DUE_TO_UNCAUGHT_EXCEPTION___ in a > stack is meaningless by itself. Many different kinds of crashes may > have this at the top of the stack.) FYI, finally got socorro to push better signature generation for signatures related to ObjC exceptions, so this crash is now "[@ objc_exception_throw | -[NSException raise] | registerNatives ]"
Summary: 1.9.x crashes in [@___TERMINATING_DUE_TO_UNCAUGHT_EXCEPTION___ ] due to Java on 10.5 and 10.6 → 1.9.x crashes in [@ objc_exception_throw | -[NSException raise] | registerNatives ] due to Java on 10.5 and 10.6
I've just released a new version of the Java Embedding Plugin (0.9.7.3) that fixes this bug (by working around it). For more information see bug 551327.
JEP 0.9.7.3 has now landed on the 1.9.2 and 1.9.1 branches, and should be in tomorrow's Firefox 3.6.3pre and 3.1.10pre nightlies (at ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/).
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Component: Java Embedding Plugin → Java (Java Embedding Plugin)
Product: Core → Plugins
Version: 1.9.2 Branch → unspecified
I'm getting crashes trying to use http://Panopticlick.eff.org. Crash reports show this as a related bug. Running FF 3.6.3 on MacOS 10.6.3. Crashes also occur browsing to this site with a new (clean) profile. See crash reports: bp-89653817-c481-4cb2-8dc7-b3e332100519 32D03230-7307-4F7E-88F9-76A117E9052F 57BFB88B-B3AE-4810-A348-7579A77E24A2 6A6532C6-C907-4B4C-8957-BAAE47FAB4D5 DFA08E2E-393E-4521-A444-524D357AA64C This is 100% reproducible on my machine. Safari, Chrome and Opera don't crash. Let me know if there's more I can do to help?
The fix for this bug didn't get into Firefox 3.6.3. It will be in FF 3.6.4, which hasn't yet been released. Please try the most recent release candidate from: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.6.4-candidates/
I tested this using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:22.214.171.124) Gecko/20100513 Firefox/3.6.4. The site in Comment 12 loads fine.
Today Apple pushed Update 2 for Java SE 6 on MacOS 10.6.3. That appears to have fixed the problem, at least at http://panopticlick.eff.org
Crash Signature: [@ objc_exception_throw | -[NSException raise] | registerNatives ]
You need to log in before you can comment on or make changes to this bug.