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

RESOLVED FIXED

Status

()

Core
Plug-ins
RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: Simon Fraser, Assigned: Josh Aas)

Tracking

({fixed1.8.0.2, fixed1.8.1})

Trunk
PowerPC
Mac OS X
fixed1.8.0.2, fixed1.8.1
Points:
---
Bug Flags:
blocking1.8.0.2 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [camino-1.0])

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
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.
(Reporter)

Updated

11 years ago
No longer blocks: 312062

Comment 1

11 years ago
Other important fixes appear in this JEP build too.
Flags: blocking1.8.0.2?
(Assignee)

Comment 2

11 years ago
Created attachment 210165 [details]
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.
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?

(Assignee)

Comment 4

11 years ago
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

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

> 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

11 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

11 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

11 years ago
Whiteboard: [camino-1.0]
Flags: blocking1.8.0.2? → blocking1.8.0.2+

Comment 10

11 years ago
I'll do ya one better: checked in a fat 0.9.5+c on the trunk and branches.  Bug 327785.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Keywords: fixed1.8.0.2, fixed1.8.1
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.