338738 - Accessing above URL crashes Camino

Status: VERIFIED FIXED

(Camino Graveyard :: Plug-ins, defect)

Description

[Paulo Nascimento]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.2) Gecko/20060425 Camino/1.0.1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.2) Gecko/20060425 Camino/1.0.1

Besides crashing Camino, Talkback is invoked.
Local Talkback incident registered as TB18952320H, for extra details.

Reproducible: Always

Steps to Reproduce:
1. Launch Camino
2. Type URL http://194.65.135.122 on the location bar
3. Wait a few seconds

Actual Results:  
Camino crashes, always.

Expected Results:  
Normal access to the page, as it is correctelly rendered and accessed by other browsers, example Camino.

Comment 1

[Daniel Veditz [:dveditz]]

The site seems to be offline, what was supposed to be there?

The crash is in Java, which is very Mac-specific. Do you know what version of Java you have? Given the suspicious numeric address for the site (registered to "Schneider Electric Portugal, Lda") was it dodgy content to begin with? Holes in old versions of Java seem to be a favorite target for malicious sites, perhaps because people are slower to upgrade Java than other parts of their system. If your java is not up to date see if upgrading it solves the problem.

Does Mac Firefox crash on the same site (if it's still up)? The JavaEmbeddingPlugin is in the stack so it would be interesting to see if Safari crashes on the same site (Apple Java problem) or just mozilla-based browsers.

Is the Mac OS X 10.3 in the "OS" field accurate? We should compare a 10.4 system.

Comment 2

[Steven Michaud [:smichaud] (Retired)]

Here's the stack trace, to preserve it (they normally get discarded
after about a week).  It contains no useful information (saying the
crash happened in libawt.jnilib is equivalent to saying it happened
somewhere in the JVM).  But it does confirm that the reporter is using
OS X 10.3.9.

Stack Signature        libawt.jnilib.1.0.0 + 0x42a78 (0x849b8a78) ade835b6
Product ID             Camino10
Build ID               2006042505
Trigger Time           2006-05-21 12:25:58.0
Platform               MacOSX
Operating System       Darwin 7.9.0
Module                 libawt.jnilib.1.0.0 + (00042a78)
URL visited
User Comments
Since Last Crash       33983 sec
Total Uptime           33983 sec
Trigger Reason         SIGBUS: Bus Error: (signal 10)
Source File, Line No.  N/A
Stack Trace

libawt.jnilib.1.0.0 + 0x42a78 (0x849b8a78)
JavaEmbeddingPlugin + 0x23890 (0x05f2d890)
AppKit.743.42.0 + 0xced08 (0x92f3ed08)
AppKit.743.42.0 + 0x6fba8 (0x92edfba8)
AppKit.743.42.0 + 0xfb6b8 (0x92f6b6b8)
libawt.jnilib.1.0.0 + 0x2af78 (0x849a0f78)
libawt.jnilib.1.0.0 + 0x2ac5c (0x849a0c5c)
libawt.jnilib.1.0.0 + 0x2aab0 (0x849a0ab0)
0x07dc8580
0x07dc1f20
0x07dc1f20
0x07dc1fb0
0x07dc1ec0
0x07dc1ec0
0x07dc1fb0
0x07dc1fb0
0x07dc1fb0
0x07dc1fb0
0x07dc1ec0
0x07dc1fb0
0x07dc1fb0
0x07dc2310
0x07dbf16c
libhotspot.dylib.1.0.0 + 0x1afe8 (0x96722fe8)
libhotspot.dylib.1.0.0 + 0x3c438 (0x96744438)
libhotspot.dylib.1.0.0 + 0x79098 (0x96781098)
libhotspot.dylib.1.0.0 + 0x89960 (0x96791960)
libhotspot.dylib.1.0.0 + 0x12e6fc (0x968366fc)
libhotspot.dylib.1.0.0 + 0x74df4 (0x9677cdf4)
libhotspot.dylib.1.0.0 + 0x1d290c (0x968da90c)
_pthread_body()

Comment 3

[Steven Michaud [:smichaud] (Retired)]

Reporter, if you can, please attach a crashreporterd log for this
crash.  It will contain far more information than the Talkback stack
trace, so you'll need to save it to a file and use "Create a New
Attachment" (above).

crashreporterd logs crashes to files in the
Library/Logs/CrashReporter/ directory under your home directory
(i.e. to ~/Library/Logs/CrashReporter/).  Camino crashes will be in a
file called Camino.crash.log.  Each new crash is appended to the end
of the file, so this file will probably contain logs of several
crashes.  To find the right one, find one whose date matches the
timestamp of the Talkback stack trace (2006-05-21 12:25:58.0).  Note
that the "hour" number might be different, due to timezone
complications.

Each new crashreporterd crash log starts with a header that looks like
this:

**********

Host Name:      swann.mynet.net
Date/Time:      2006-04-12 16:15:23 -0500
OS Version:     10.3.9 (Build 7W98)
Report Version: 2

Comment 4

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

Attachment: crashlog (1.8branch, 10.3.9)

Steven, here's the crash log I got from loading the site in 10.3.9 with a branch nightly.

Comment 5

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

Attachment: JavaNativeCrash log associated with the crash

Here's the JavaNativeCrash.log, which looks like it might actually be semi-useful as opposed to most of the ones I've seen :)

Comment 6

[Steven Michaud [:smichaud] (Retired)]

Smokey, is there any chance that you still have the
~/Library/Logs/Java Console.log corresponding to your crash?

Look right now, before you restart your browser (or load another Java
applet) -- that file gets overwritten every time you restart the
browser and load another applet.

Comment 7

[Steven Michaud [:smichaud] (Retired)]

The crashreporterd crash log (attachment 223060 [details]) seems to be corrupt
-- PoseAsNSScroller() (in Handlers.m) is only ever called from
[JEPController checkBundle] (in Controller.m), and checkBundle is
always called from the MRJ Plugin JEP, and then only on the main
thread.  (It's unlikely that the call to PoseAsNSScroller() is due to
a corrupt stack -- that routine doesn't call [NSScrollViewAWT peer],
directly or indirectly.)

That's probably why the JavaNativeCrash.log (attachment 223060 [details]) is
more informative than usual.  But I can't make any more of what it
contains than the following:  The applet that crashed is called
ZoneFavoris, and the crash occurred during its init() method.

Comment 8

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

Attachment: Java Console.log from reproduction of the crash

Well, I didn't get there in time, but I went and crashed Camino again--I think as long as the site is up, we'll be able to crash relaiably ;) --and the crash log and Java Native Crash log were identical to the first (with the exception of those hex sequences), so here's the Java Console.log from the second crash.

Comment 9

[Steven Michaud [:smichaud] (Retired)]

Thanks! ... but (as you must have seen) your Java Console.log doesn't
tell us anything :-(

However, I didn't realize this site was back up.  I've now gone there
and had my own crash.  I'll see what I can find out.

Comment 10

[Steven Michaud [:smichaud] (Retired)]

I've found a fix, I think.

It was an obscure problem with stuff I was doing in an undocumented
method of an undocumented class ([NSScrollViewAWT
reflectScrolledClipView]), probably triggered by the fact that the
method was being called so early (in the applet's init() method).  I
will need to check my fix in other Mozilla.org browsers and on other
OSes (I've been testing on OS X 10.3.9).  But if everthing goes well,
I should be able to include this fix in my next JEP release (0.9.5+e).

Comment 11

[Paulo Nascimento]

Reply to comment #1 From Daniel Veditz  2006-05-21 20:49 PDT

The site is always online, it's a comercial site belonging to an electrical multi-national company very well known in Europe. I have no special relation with the company, except as consulting data related to my job.

My version of Java is:
[PowerBook-G4:~] pnascim% java -version
java version "1.4.2_09"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_09-233)
Java HotSpot(TM) Client VM (build 1.4.2-56, mixed mode)

So my Java software is uptodate.

Yes, I agree a numerical ip address is odd but let's not blame them on it... and I don't agree at all this could be considered a malicious site, it's a comercial one for public access and probably hosting the "Electronic catalog" web-application, so it seems at least.

Don't know if Firefox crashes on the same (don't use it), Safari doesn't and Mozilla 1.8b either! Already said before Safari doesn't crash on that url.

Yes, I'm running Mac OS X 10.3.9, you should trust the field accuracy, it's correct.

I'm going to include my crash log as an attachment.
Guys, I'm not an expert on debugging software, but personally I believe that fixing this issue will solve many "unexplained" crashes in Camino. This is not the first Camino crash I see related with java applets, this time I decide to invest a little bit more of my time, hope you all appreciate that. 

Comment 12

[Paulo Nascimento]

Attachment: The ~ crash log

Comment 13

[Steven Michaud [:smichaud] (Retired)]

> The site is always online

Not when I tried it, several times, over the last couple of days.

> personally I believe that fixing this issue will solve many
> "unexplained" crashes in Camino

Very unlikely:  I did find a bug in the JEP (and I fixed it -- see
comment #10).  But it's a very obscure bug, unlikely to effect many
other Java applets (or web sites).

That doesn't mean I'm not grateful for your report -- without it I
wouldn't have been able to find this bug.

If you want to help find more bugs, please keep filing more reports.
And if you're reporting a crash bug, please attach a copy of the
crashreporterd crash log -- it's _much_ more useful than a Talkback
log.

(The JEP is the Java Embedding Plugin, which is bundled with recent
versions of Mozilla.org browsers.  It's needed to allow these browsers
to use Apple's most recent Java versions -- which would otherwise only
work with Safari.  I'm the JEP's author.)

Comment 14

[Steven Michaud [:smichaud] (Retired)]

*** Bug 339366 has been marked as a duplicate of this bug. ***

Comment 15

[Steven Michaud [:smichaud] (Retired)]

I've just released a new version (0.9.5+e) of the Java Embedding
Plugin that fixes this bug:

http://javaplugin.sourceforge.net/

Please follow the Readme's instructions to install the new JEP to your
/Library/Internet Plug-Ins/ folder, and to remove older copy(ies) of
the JEP from your Mozilla.org browser(s).

Comment 16

[Bob Seegal]

Loaded the Java Embedding Plug in as directed.  It cures the crash problem I encounted at www.prophet.net with Camino 1.0.1

Comment 17

[Paulo Nascimento]

(In reply to comment #15)
> I've just released a new version (0.9.5+e) of the Java Embedding
> Plugin that fixes this bug:
> 
> http://javaplugin.sourceforge.net/
> 
> Please follow the Readme's instructions to install the new JEP to your
> /Library/Internet Plug-Ins/ folder, and to remove older copy(ies) of
> the JEP from your Mozilla.org browser(s).
> 

Hi there,

I did the JavaEmbeddingPlugin0.9.5+e installation as described in fellow read me file, and good news is that Camino no longer crashes at the given address. The bad news (just for me) is that the page at given address still doesn't render correctelly, but maybe not JEPs fault I think, other non-Gecko based browsers render it correctelly (read Safari). By good rendering I mean Safari allows the java plugin to start as opposed to Camino 1.0.1 where the java plugins gets stalled.

By the way, the original datetime stamps were:

349689 16 -rwxrwxr-x   1 pnascim  staff   963  4 Dec  2004 Java Applet Plugin Enabler
349688  0 drwxrwxr-x   3 pnascim  staff   102 18 May  2004 Java Applet.plugin

Regards,

--
Paulo Nascimento

Comment 18

[Steven Michaud [:smichaud] (Retired)]

> good news is that Camino no longer crashes at the given address

Glad to hear it.

> The bad news (just for me) is that the page at given address still
> doesn't render correctelly, but maybe not JEPs fault I think, other
> non-Gecko based browsers render it correctelly (read Safari). By
> good rendering I mean Safari allows the java plugin to start as
> opposed to Camino 1.0.1 where the java plugins gets stalled.

I don't have this problem.  Do you see it all the time?  Do you see it
in Firefox or Seamonkey (on OS X or on other platforms like Windows
and Linux)?

Also, what exactly do you mean by "gets stalled"?  Does the applet not
display?  Does it stop displaying for a short time and then start up
again?

Comment 19

[Paulo Nascimento]

Attachment: Problematic URL works fine in IE6 under WinXP.

Comment 20

[Stuart Morgan]

Closing as fixed based on comment 17; the bug is about a crash, and it no longer crashes. Any remaining, non-crash problems should be handled in a new bug.