bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

Page load leads to crash, possible Java-related



Core Graveyard
Java: OJI
17 years ago
8 years ago


(Reporter: Kurt Swanson, Assigned: Joe Chou)


({crash, stackwanted})

crash, stackwanted

Firefox Tracking Flags

(Not tracked)




(2 attachments)



17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010802
BuildID:    2001080221

Upon loading the page, mozilla crashes.  There are three small applets
that are attempted to be loaded.

Reproducible: Always
Steps to Reproduce:
1. Load page

Actual Results:  crash

Expected Results:  not crash

Comment 1

17 years ago
Reporter we need a talkback id or stacktrace for this report to be useful.
Keywords: crash, stackneeded

Comment 2

17 years ago
I had reported this bug from the linux rpm edition of the build, which lacks
talkback, nor could I figure out how to get a stack trace (how does one run the
rpm version with a debugger?); I thus installed a talkback version in a user
account.  Upon loading the site, I of course needed java, got the plugin and
restarted mozilla twice as required (MS WINDOWS DEJA VU!!!!).

The page loaded without a problem.

I thus checked to see if the java plugin installed for the rpm version was
different--nope identical .so files.  For the hell of it, I removed the java
plugin from the rpm version, reloaded it, and presto everything works.

This is quite strange when the plugins were identical, and the first instance
worked for every other java-enabled page I tried...

Comment 3

17 years ago
Chris, any ideas why it wouldnt work on the RPM builds?

Comment 4

17 years ago
| ./mozilla -g | should get mozilla running in a debugger
could it be the component.reg wasn't correct?

Comment 5

17 years ago
Tried this page with a debug build from 8/17. When scrolling down and up while
the page is loading, I get the following assertion:

###!!! ASSERTION: You can't draw an image with a 0 width or height!: 'aSWidth >
0 && aDWidth > 0 && aSHeight > 0 && aDHeight > 0', file
../../../../mozilla/gfx/src/gtk/nsImageGTK.cpp, line 563

I can't get the page to finish loading all its images, but I didn't crash.
On the first time, I somehow managed to hang the browser with a mixture of
clicking on the link to /prequal.html, clicking stop, back, and/or reload.
When it locked up, there were 5 threads, all in suspend or poll, but only one
had an interesting stack. I'm going to attach it, just if someone is interested.

Comment 6

17 years ago
Created attachment 46379 [details]
stack trace of thread 1 in a random lock-up situation

Comment 7

17 years ago
Using build 2001090721 on RH6.2, I also crash, I used JRE 1.3.1 (without Flash
loaded as it could be then a dup of bug 86591).
I get no Talkback data but the JRE outputs error in console and saves it to a
file which I'll attach next. But a signal 11 perhaps means nothing (my PC
sometimes has Sig11 errors http://www.bitwizard.nl/sig11/), however, this page
triggers it everytime.

Comment 8

17 years ago
Created attachment 48690 [details]
File created by JRE 1.3.1 when Mozilla crashed

Comment 9

17 years ago
I see this crash too with 2001-09-07-21 on Linux. I'm using j2sdk 1.3.1_01.

I also got a similar log as Olivier Cahagne and I will attach it if anyone wants it.

Comment 10

17 years ago
I managed to get a backtrace of this crash:

#0  0x4049997e in sigsuspend () from /lib/libc.so.6
#1  0x401d05a9 in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0
#2  0x401ccf82 in pthread_cond_wait () from /lib/libpthread.so.0
#3  0x401b40e9 in PR_WaitCondVar () from /home/andre/apps/mozilla/libnspr4.so
#4  0x4012ee55 in nsThreadPool::GetRequest () from
#5  0x4012f4ce in nsThreadPoolRunnable::Run () from
#6  0x4012e2aa in nsThread::Main () from /home/andre/apps/mozilla/libxpcom.so
#7  0x401b864e in PR_Select () from /home/andre/apps/mozilla/libnspr4.so
#8  0x401cde85 in pthread_start_thread () from /lib/libpthread.so.0
#9  0x401cdecd in pthread_start_thread_event () from /lib/libpthread.so.0


17 years ago
Ever confirmed: true

Comment 11

17 years ago
This is a duplicate of 95661

It is due to a very badly writte piece of java that causes loads of nullpointer
and security exceptions that consume 100% processor load for stack traces.

Comment 12

17 years ago
anyone to confirm dupe of bug 95661 ?

Comment 13

17 years ago
Assignee: asa → edburns
Component: Browser-General → OJI
QA Contact: doronr → pmac

Comment 14

17 years ago
Reassign to Joe as I'm leaving the role of OJI module owner.
Target Milestone: --- → mozilla0.9.5

Comment 15

17 years ago
Ressign to Joe Chou, as I am no longer working officially on OJI.
Assignee: edburns → joe.chou
Target Milestone: mozilla0.9.5 → mozilla0.9.6

Comment 16

17 years ago
Works for me (no crash and applets work) 20011001 on Solaris (trunk build)

Comment 17

17 years ago
WFM on recent trunk build and RedHat 6.2
Not a dupe of 95661 because i can reproduce that crash.

Comment 18

17 years ago
wfm using build 2001103113 on Linux (RH 6.2, glibc 2.1.3) + JRE 1.3.0_01.
Too late for 0.9.6, this needs retargeting.

Comment 20

17 years ago
Tried it with trunk build today with jre1.3.0_01, and it brought up the page
without crashing.
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Comment 21

16 years ago
Chris Petersen is a new QA contact for oji component. His email is:
Assignee: joe.chou → petersen
fixing small error for pmac@netscape.com (filter with : SPAMMAILSUCKS)
Assignee: petersen → joe.chou
QA Contact: pmac → petersen


8 years ago
Component: Java: OJI → Java: OJI
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.