325147 - New version of JEP (0.9.5+c), please land on trunk and branch

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Simon Fraser [no longer active]]

Steven just released a new version of the JEP that fixes a serious crasher for Camino (bug 312062). We need this on branch and trunk.

Comment 1

[Mark Mentovai]

Other important fixes appear in this JEP build too.

Comment 2

[Josh Aas]

Attachment: FF 1.5, 10.4.4 crash log

This version of JEP crashed almost immediately for me, on this page:

http://java.sun.com/applets/other/Bullets/alphabullet.html

PPC 10.4.4, Firefox 1.5

I'm going to hold off on landing.

Comment 3

[Steven Michaud [:smichaud] (Retired)]

This isn't a crash in JEP code, so the JEP may not be involved.

I don't see any crash at all, even when I reloaded rapidly several times in a
row.  Try to see if you get a crash using Java 1.3.1.

Does anyone else crash on this URL?

Comment 4

[Josh Aas]

I can't reproduce any more. And the fact that there are 20 applets on that page explains all the threads.

Landed on trunk.

Comment 5

[Simon Fraser [no longer active]]

Comment on attachment 210165 [details]
FF 1.5, 10.4.4 crash log

>24  talkback.dylib                 	0x018a4e00 FCProcessSignal(int, UNIX_EXCEPTION_CONTEXT*) + 152
>25  talkback.dylib                 	0x018a74f4 fcStackDumpCollectorCreator(unsigned long, char*, int, char**) + 360

This is actually Talkback crashing while generating the crash info.

Comment 6

[Steven Michaud [:smichaud] (Retired)]

Yes, but thread 0 (the likeliest source of whatever trouble caused Talkback to
be launched) is somewhere in the JVM, probably not in JEP code.

Does Talkback always get launched in its own thread?

Comment 7

[Steven Michaud [:smichaud] (Retired)]

> Does Talkback always get launched in its own thread?

Oops, now I see it.  From the bottom of the thread 8 stack, you can tell that
something tried to launch a thread with a NULL pointer, libSystem.B.dylib
caught it, and then Talkback got into the act.

But this new thread was still most likely launched from thread 0.

I assume that the fact that this is "thread 8" (instead of having the highest
number) means that the previous thread 8 died (possibly a normal death) just
before something tried to launch this thread 8.

Or maybe the stack trace is just corrupt :-)

Comment 8

[Simon Fraser [no longer active]]

(In reply to comment #7)
> > Does Talkback always get launched in its own thread?
> 
> Oops, now I see it.  From the bottom of the thread 8 stack, you can tell that
> something tried to launch a thread with a NULL pointer, libSystem.B.dylib
> caught it, and then Talkback got into the act.

Talkback runs its signal handlers on a thread, because the thread that crashed may have run out of stack space. I think thread 8 is just talkback doing its thing (the null frame is benign, I think). I don't see any other threads doing bad stuff, so have no idea what this crash is.

Comment 9

[Mark Mentovai]

A fat JEP has been checked into CAMINO_1_0_BRANCH.  This is JEP 0.9.5+c with x86 bits produced using the patches in bug 315163 merged in using lipo.

Comment 10

[Mark Mentovai]

I'll do ya one better: checked in a fat 0.9.5+c on the trunk and branches.  Bug 327785.