525566 - 1.9.x crashes in [@ objc_exception_throw | -[NSException raise] | registerNatives ] due to Java on 10.5 and 10.6

Status: RESOLVED FIXED

(Plugins Graveyard :: Java (Java Embedding Plugin), defect)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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).

Comment 1

[Steven Michaud [:smichaud] (Retired)]

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.)

Comment 2

[Steven Michaud [:smichaud] (Retired)]

Interestingly, none of these crashes appear to be older than 2009-09-01.

Comment 3

[Steven Michaud [:smichaud] (Retired)]

I suspect this means Breakpad wasn't keeping track of them before then.

Comment 4

[Samuel Sidler (old account; do not CC)]

(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/

Comment 5

[Steven Michaud [:smichaud] (Retired)]

The one thing we can be sure of is these crashes didn't start happening on 2009-09-01 :-)

Comment 6

[Steven Michaud [:smichaud] (Retired)]

We can also be sure they didn't start happening much more frequently on that date.

Comment 7

[Steven Michaud [:smichaud] (Retired)]

> 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.

Comment 8

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 9

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(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 ]"

Comment 10

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 11

[Steven Michaud [:smichaud] (Retired)]

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/).

Comment 12

[Richard A Milewski[:richard]]

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?

Comment 13

[Steven Michaud [:smichaud] (Retired)]

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/

Comment 14

[Marcia Knous [:marcia]]

I tested this using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100513 Firefox/3.6.4. The site in Comment 12 loads fine.

Comment 15

[Richard A Milewski[:richard]]

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