100702 - Site crashed mozilla. Right after loading java plugin

Status: VERIFIED FIXED

(Core Graveyard :: Java: OJI, defect)

Description

[r.navalinskas]

Entering www.javasoft.com 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

[Jerome Lacoste]

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
[e-mail] 2001-09-17 18:13)

Is this one a dupe of the bug 78442?

Comment 2

[Christopher Aillon (sabbatical, not receiving bugmail)]

Could also be topcrash,top100 bug 86591.

Comment 3

[r.navalinskas]

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

Comment 4

[WD]

Confirming WinMe 2001091903 w/ JRE 1.3.1_01a

TB35645809G
TB35646180W

Not sure if it's related but see also bug 95661

Comment 5

[R.K.Aa.]

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 libgklayout.so
#5  0x4141b74b in NSGetModule () from libgkplugin.so
#6  0x415c7116 in JavaPluginInstance5::Initialize () from
/usr/local/jre1.3.1/plugin/i386/ns600/libjavaplugin_oji.so
#7  0x41415575 in NSGetModule () from libgkplugin.so
#8  0x414148bc in NSGetModule () from libgkplugin.so
#9  0x416ed92c in NSGetModule () from libgklayout.so
...(identical)
#70 0x416feadc in NSGetModule () from libgklayout.so
#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 libwidget_gtk.so
#75 0x40c84c38 in NSGetModule () from libwidget_gtk.so
#76 0x4036ea7a in g_io_unix_dispatch (source_data=0x83267b0,
current_time=0xbffff1d0, 
    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 ()
   from libwidget_gtk.so
#82 0x406c791e in NSGetModule ()
   from libnsappshell.so
#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,
ubp_av=0xbffff71c, 
    init=0x804b7cc <_init>, fini=0x8052240 <_fini>, rtld_fini=0x4000e184
<_dl_fini>, 
    stack_end=0xbffff70c) at ../sysdeps/generic/libc-start.c:129

Comment 6

[Greg K.]

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

Comment 7

[Jens-Uwe]

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)

Comment 8

[Tobias Weibel]

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)

TB35658895M

Comment 9

[Tracy Walker [:tracy]]

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 
down...my stacks are still waiting in queue to be sent.

Comment 10

[basic]

reasigning to default

Comment 11

[WD]

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

Comment 12

[Tobias Weibel]

additional talkbacks:
TB35695850M
TB35695827H
TB35659130Q

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 13

[Tracy Walker [:tracy]]

this is a smoketest blocker

Comment 14

[J.J. Enser]

can we get some traction on this? no activity since bug severity rose to
blocker, 90 mn. ago, keeping the mozilla tree closed.

Comment 15

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: stacks for all talkback reports mentioned in bug

Comment 16

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

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

[Paul Chen]

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

[edburns]

I'm looking at this now.

Comment 19

[Dave]

Looks like all stacks in the attachement are win32, see bug 100949 for Linux
talkbacks.

Comment 20

[Matthias Versen [:Matti]]

*** Bug 100961 has been marked as a duplicate of this bug. ***

Comment 21

[Paul Chen]

backing out edburns changes in nsObjectFrame.cpp here:
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=&subdir=mozilla/layout/html/base/src&command=DIFF_FRAMESET&root=&file=nsObjectFrame.cpp&rev1=1.254&rev2=1.255

crash seems to go away. Steps were 1) rollback to version 2.54, nmake -f
client.mak build_all, run mozilla, no crash at java.sun.com, 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
java.sun.com, 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

[Peter Lubczynski]

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

Comment 23

[Paul Chen]

Attachment: remove extra lines caused by misapplied patch

Comment 24

[Paul Chen]

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

Comment 25

[Paul Chen]

fix checked into trunk

Comment 26

[lohphat]

http://www.nextbus.com/predictor/publicMap.shtml?a=MUNI&r=J

This page works OK with java while the original test case does not.

Comment 27

[Tracy Walker [:tracy]]

verified on commercial trunk builds:

windows 2001-09-24-05-trunk
linux2001-09-24-06-trunk