Closed
Bug 325147
Opened 19 years ago
Closed 18 years ago
New version of JEP (0.9.5+c), please land on trunk and branch
Categories
(Core Graveyard :: Plug-ins, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: sfraser_bugs, Assigned: jaas)
Details
(Keywords: fixed1.8.0.2, fixed1.8.1, Whiteboard: [camino-1.0])
Attachments
(1 file)
63.37 KB,
text/plain
|
Details |
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.
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•19 years ago
|
||
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?
I can't reproduce any more. And the fact that there are 20 applets on that page explains all the threads. Landed on trunk.
Reporter | ||
Comment 5•19 years ago
|
||
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•19 years ago
|
||
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•19 years ago
|
||
> 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 :-)
Reporter | ||
Comment 8•19 years ago
|
||
(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•19 years ago
|
||
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.
Updated•19 years ago
|
Whiteboard: [camino-1.0]
Updated•19 years ago
|
Flags: blocking1.8.0.2? → blocking1.8.0.2+
Comment 10•18 years ago
|
||
I'll do ya one better: checked in a fat 0.9.5+c on the trunk and branches. Bug 327785.
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•