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.
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 firstname.lastname@example.org 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
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.
Confirming WinMe 2001091903 w/ JRE 1.3.1_01a TB35645809G TB35646180W Not sure if it's related but see also bug 95661
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
Site generates a "java.lang.nullPointerException" using Mac/0.9.4.
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
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
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.
reasigning to default
Assignee: asa → edburns
QA Contact: doronr → pmac
*** Bug 100949 has been marked as a duplicate of this bug. ***
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)
this is a smoketest blocker
Severity: critical → blocker
can we get some traction on this? no activity since bug severity rose to blocker, 90 mn. ago, keeping the mozilla tree closed.
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.
this started happening with 2001-09-19-05-trunk builds, 2001-09-17-05-trunk and 2001-09-18-05-trunk builds work fine
I'm looking at this now.
Status: NEW → ASSIGNED
Looks like all stacks in the attachement are win32, see bug 100949 for Linux talkbacks.
*** Bug 100961 has been marked as a duplicate of this bug. ***
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!).
Looks like the patch was miss-applied. The orriginal patch in bug 98107 just shows the addition of two lines.
Removing those extra lines fixes the crash. Anyone object to checking this in? ;-)
fix checked into trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
http://www.nextbus.com/predictor/publicMap.shtml?a=MUNI&r=J This page works OK with java while the original test case does not.
verified on commercial trunk builds: windows 2001-09-24-05-trunk linux2001-09-24-06-trunk
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.