Site crashed mozilla. Right after loading java plugin



Core Graveyard
Java: OJI
17 years ago
4 years ago


(Reporter: r.navalinskas, Assigned: edburns)


({crash, smoketest, stackwanted})

crash, smoketest, stackwanted

Firefox Tracking Flags

(Not tracked)




(2 attachments)



17 years ago
Entering crashes mozilla (build 2001091903 on Win2000 Pro),
right after java plugin is loaded. Perhaps it's plugin problem, but I'm not
sure, so I'm putting in browser-general section.

Comment 1

17 years ago
Reporter, is there a talkback for that crash?

There have been many crashed reported to Java plugin installation these days.
The reopened bug 78442 has a comment about that (Additional Comments From 2001-09-17 18:13)

Is this one a dupe of the bug 78442?

Could also be topcrash,top100 bug 86591.
Severity: normal → critical
Keywords: crash, stackwanted

Comment 3

17 years ago
I didn't have any expierence with talkback, so no news from here. But I also
found directly oposite crashing scheme: go to , there java plugin is
loaded(without crashing), but then go to some other page like, and
only then crash occurs.

Comment 4

17 years ago
Confirming WinMe 2001091903 w/ JRE 1.3.1_01a


Not sure if it's related but see also bug 95661
Ever confirmed: true

Comment 5

17 years ago
the same site repeatedly crashes in bug 86591.
However - there may be a new crash in town - or it's just morphing as new builds
stage; on a current linux CVS build this one now crashed me in

#0  0x4051c34a in chunk_alloc (ar_ptr=0x405c5f00, nb=16) at malloc.c:2782
#1  0x4051c13a in __libc_malloc (bytes=5) at malloc.c:2714
#2  0x401993e6 in PL_strdup () at eval.c:41
#3  0x40162263 in nsString::ToNewUTF8String () at eval.c:41
#4  0x416f15bd in NSGetModule () from
#5  0x4141b74b in NSGetModule () from
#6  0x415c7116 in JavaPluginInstance5::Initialize () from
#7  0x41415575 in NSGetModule () from
#8  0x414148bc in NSGetModule () from
#9  0x416ed92c in NSGetModule () from
#70 0x416feadc in NSGetModule () from
#71 0x40131f67 in PL_HandleEvent () at eval.c:41
#72 0x40131e61 in PL_ProcessPendingEvents () at eval.c:41
#73 0x40132f2f in nsEventQueueImpl::ProcessPendingEvents () at eval.c:41
#74 0x40c84ed6 in NSGetModule () from
#75 0x40c84c38 in NSGetModule () from
#76 0x4036ea7a in g_io_unix_dispatch (source_data=0x83267b0,
    user_data=0x8326788) at giounix.c:137
#77 0x40370055 in g_main_dispatch (dispatch_time=0xbffff1d0) at gmain.c:656
#78 0x40370659 in g_main_iterate (block=1, dispatch=1) at gmain.c:877
#79 0x403707e8 in g_main_run (loop=0x8326828) at gmain.c:935
#80 0x4028565b in gtk_main () at gtkmain.c:524
#81 0x40c853b5 in NSGetModule ()
#82 0x406c791e in NSGetModule ()
#83 0x08050bb5 in NS_CreateNativeAppSupport () at eval.c:41

#84 0x080514c5 in main () at eval.c:41
#85 0x404b9177 in __libc_start_main (main=0x805138c <main>, argc=1,
    init=0x804b7cc <_init>, fini=0x8052240 <_fini>, rtld_fini=0x4000e184
    stack_end=0xbffff70c) at ../sysdeps/generic/libc-start.c:129

Comment 6

17 years ago
Site generates a "java.lang.nullPointerException" using Mac/0.9.4.

Comment 7

17 years ago
this page displays fine here 2001091909 linux but crashes reproducable when I
want to go to a different page.
component = OJI, plattform = ALL (after report of Win, Mac and Linux)
Component: Browser-General → OJI
OS: Windows 2000 → All
Hardware: PC → All

Comment 8

17 years ago
Confirming Win2k 2001091903 

java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)


Comment 9

17 years ago
seeing this on trunk build for windows 2001-09-20-11-trunk (branch was okay)

I believe this is a new bug.  Flash is working fine and the crash does not cause 
an OS freeze.  Those behaviors were mentioned in bugs previously noted here.

I can't get a talk back report because the talk back server seems to be stacks are still waiting in queue to be sent.

Comment 10

17 years ago
reasigning to default
Assignee: asa → edburns
QA Contact: doronr → pmac

Comment 11

17 years ago
*** Bug 100949 has been marked as a duplicate of this bug. ***

Comment 12

17 years ago
additional talkbacks:

Win2k 2001091903

java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)
this is a smoketest blocker
Severity: critical → blocker
Keywords: smoketest

Comment 14

17 years ago
can we get some traction on this? no activity since bug severity rose to
blocker, 90 mn. ago, keeping the mozilla tree closed.
Created attachment 50276 [details]
stacks for all talkback reports mentioned in bug
Attachment #50276 - Attachment description: stacks for all talkback reports mentioned ni bug → stacks for all talkback reports mentioned in bug
The stacks are all different, so this seems like something writing to memory it
doesn't own.  If that's the case, figuring it out probably either requires
running with Purify or guessing which checkins to back out to see if it goes away.

Comment 17

17 years ago
this started happening with 2001-09-19-05-trunk builds, 2001-09-17-05-trunk and
2001-09-18-05-trunk builds work fine

Comment 18

17 years ago
I'm looking at this now.

Comment 19

17 years ago
Looks like all stacks in the attachement are win32, see bug 100949 for Linux
*** Bug 100961 has been marked as a duplicate of this bug. ***

Comment 21

17 years ago
backing out edburns changes in nsObjectFrame.cpp here:

crash seems to go away. Steps were 1) rollback to version 2.54, nmake -f
client.mak build_all, run mozilla, no crash at, 2) update
nsObjectFrame.cpp back to tip (cvs up -A nsOjbectFrame.cpp, which gives me
version 2.56), nmake -f client.mak build_all, run mozilla, crash at, 3) manually undo edburns checkin from 2.55 in nsObjectFrame.cpp,
nmake -f client.mak build_all, run mozilla, no crash, going to another page also
doesn't crash

What worries me is that rolling back to 2.54 should've cause lots of problems
because karnaze added an extra parameter to nsObjectFrame::Paint() in 2.56 and
that didn't cause problems (oh, you know, like, link errors!).

Comment 22

17 years ago
Looks like the patch was miss-applied. The orriginal patch in bug 98107 just
shows the addition of two lines.

Comment 23

17 years ago
Created attachment 50300 [details] [diff] [review]
remove extra lines caused by misapplied patch

Comment 24

17 years ago
Removing those extra lines fixes the crash. Anyone object to checking this in? ;-)

Comment 25

17 years ago
fix checked into trunk
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 26

17 years ago

This page works OK with java while the original test case does not.
verified on commercial trunk builds:

windows 2001-09-24-05-trunk


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.