Closed Bug 74848 Opened 25 years ago Closed 25 years ago

crash on startup w/ java plugin installed

Categories

(Core Graveyard :: Profile: BackEnd, defect)

x86
Windows 98
defect
Not set
blocker

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: tracy, Assigned: shaver)

References

Details

(Keywords: smoketest)

Attachments

(7 files)

seen on windows commercial build 2001-04-05-06-trunk -launch the application if you don't have multiple profiles the app crashes in the spalsh screen -if you have mutltiple profiles, select one and start the app CRASH!! -also do any sort of management on a profile...create a new one, delete one, rename one CRASH!!
Keywords: smoketest
I can confirm this on Windows NT4, Service pack 6, same build.
I was able to launch using netscp6.exe -P "profile" from the console but as soon as I did anything like click on Home...it crashed also. I'll post a talkback report of that shortly.
Incident ID 28697850 Trigger Time 2001-04-05 07:08:49 Email Address twalker@netscape.com Client IP Address 208.12.37.42 User Comments crash just after launch Build ID 2001040506 Product ID Netscape6.50 Platform ID Win32 Stack Trace JS3250.DLL + 0x6fc7 (0x60bd6fc7) JS3250.DLL + 0x15401 (0x60be5401) JS3250.DLL + 0x15664 (0x60be5664) JS3250.DLL + 0x16755 (0x60be6755) JS3250.DLL + 0x1666e (0x60be666e) JSDOM.DLL + 0xa658 (0x60c2a658) JSDOM.DLL + 0xa6cd (0x60c2a6cd) JSDOM.DLL + 0x1313 (0x60c21313) XPCOM.DLL + 0x15c0 (0x60e115c0) DOCSHELL.DLL + 0x6540 (0x60126540) GKVIEW.DLL + 0x46bf (0x604446bf) GKLAYOUT.DLL + 0x61272 (0x60361272) GKLAYOUT.DLL + 0x7d15 (0x60307d15) DOCSHELL.DLL + 0x6540 (0x60126540) GKLAYOUT.DLL + 0x608d3 (0x603608d3) GKLAYOUT.DLL + 0x61272 (0x60361272) GKLAYOUT.DLL + 0x7d15 (0x60307d15) GKLAYOUT.DLL + 0x9ad4 (0x60309ad4) GKLAYOUT.DLL + 0xd48f (0x6030d48f) GKLAYOUT.DLL + 0x9ad4 (0x60309ad4) GKLAYOUT.DLL + 0xd48f (0x6030d48f) GKLAYOUT.DLL + 0x2866b (0x6032866b) GKLAYOUT.DLL + 0x9ad4 (0x60309ad4) GKLAYOUT.DLL + 0xd48f (0x6030d48f) GKLAYOUT.DLL + 0x2866b (0x6032866b) GKLAYOUT.DLL + 0x9ad4 (0x60309ad4) GKLAYOUT.DLL + 0xd48f (0x6030d48f) GKLAYOUT.DLL + 0x2866b (0x6032866b) GKLAYOUT.DLL + 0x9ad4 (0x60309ad4) GKLAYOUT.DLL + 0xd48f (0x6030d48f) GKLAYOUT.DLL + 0x2866b (0x6032866b) GKLAYOUT.DLL + 0x9ad4 (0x60309ad4) GKLAYOUT.DLL + 0xd48f (0x6030d48f) GKLAYOUT.DLL + 0x2866b (0x6032866b) GKLAYOUT.DLL + 0x9ad4 (0x60309ad4) GKLAYOUT.DLL + 0xd48f (0x6030d48f) GKLAYOUT.DLL + 0x56ac5 (0x60356ac5) GKLAYOUT.DLL + 0x552ca (0x603552ca) GKLAYOUT.DLL + 0x561bb (0x603561bb) GKLAYOUT.DLL + 0x81a47 (0x60381a47) GKLAYOUT.DLL + 0x1223 (0x60301223) XPCOM.DLL + 0x100c (0x60e1100c) GKCONTENT.DLL + 0x5634b (0x015d634b) GKCONTENT.DLL + 0x255b9 (0x015a55b9) XPCOM.DLL + 0x15c0 (0x60e115c0) DOCSHELL.DLL + 0x6540 (0x60126540) XPCOM.DLL + 0x100c (0x60e1100c) APPSHELL.DLL + 0x55ac (0x600955ac) DOCSHELL.DLL + 0x6540 (0x60126540) APPSHELL.DLL + 0x3b1e (0x60093b1e) APPSHELL.DLL + 0x55ac (0x600955ac) APPSHELL.DLL + 0x66fb (0x600966fb) APPSHELL.DLL + 0x1a10 (0x60091a10) GKWIDGET.DLL + 0x2703 (0x60b82703) GKWIDGET.DLL + 0x3359 (0x60b83359) GKWIDGET.DLL + 0x3e27 (0x60b83e27) GKWIDGET.DLL + 0x184e (0x60b8184e) GKWIDGET.DLL + 0x16b9 (0x60b816b9) KERNEL32.DLL + 0x363b (0xbff7363b) KERNEL32.DLL + 0x24407 (0xbff94407)
-> valeski
Assignee: ccarlen → valeski
Can someone reproduce this with a more informative (line numbers) stack? I'm rebuilding (mozilla) now to try and catch it.
re-pulling and building (windows). I'll have some insight soon.
confirm for Windows NT Version 4.0 ( Build 1381: Service pack 4) Downloaded from http://ftp.mozilla.org/pub/mozilla/nightly/latest/ mozilla-win32-installer.exe 05-Apr-2001 07:20 7.8M Moz crashed upon installation launch using my usual profile. I deleted the profile, moz crashed, but profile was deleted. I attempted to create a profile ( same name ) , moz crashed I deleted all the directories including C;\Program Files\Internet Explorer\Application Data\Mozilla I reran the install, it took the copy from netscape 4 path. still crashed
windows 2000 pull at 8:30am today, debug build. I can't repro any profile manager related crashes. I've run w/ -ProfileManager, created new profiles, started existing profiles, etc. All is fine on that front. Once the browser comes up though, I wind up asserting in the parser after a url load begins. Stack: nsDebug::Assertion(const char * 0x023f9084, const char * 0x023f9068, const char * 0x023f903c, int 364) line 286 + 13 bytes nsCParserNode::ReleaseAll() line 364 + 35 bytes nsCParserNode::~nsCParserNode() line 104 nsCParserNode::`scalar deleting destructor'(unsigned int 0) + 15 bytes nsCParserNode::Destroy(nsCParserNode * 0x00d0bd98, nsFixedSizeAllocator & {...}) line 105 nsCParserNode::Release(nsFixedSizeAllocator & {...}) line 68 + 13 bytes CNavDTD::HandleCommentToken(CToken * 0x00df35f8) line 2187 + 29 bytes CNavDTD::HandleToken(CNavDTD * const 0x044da970, CToken * 0x00df35f8, nsIParser * 0x0526dc20) line 872 + 12 bytes CNavDTD::BuildModel(CNavDTD * const 0x044da970, nsIParser * 0x0526dc20, nsITokenizer * 0x044da6c0, nsITokenObserver * 0x00000000, nsIContentSink * 0x0500ceb0) line 516 + 20 bytes nsParser::BuildModel() line 2028 + 34 bytes nsParser::ResumeParse(int 1, int 0) line 1909 + 11 bytes nsParser::OnDataAvailable(nsParser * const 0x0526dc28, nsIRequest * 0x04fd8ba0, nsISupports * 0x00000000, nsIInputStream * 0x044dd640, unsigned int 0, unsigned int 4684) line 2358 + 19 bytes nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x04fe53b0, nsIRequest * 0x04fd8ba0, nsISupports * 0x00000000, nsIInputStream * 0x044dd640, unsigned int 0, unsigned int 4684) line 259 + 46 bytes nsHTTPFinalListener::OnDataAvailable(nsHTTPFinalListener * const 0x04fe5360, nsIRequest * 0x04fd8ba0, nsISupports * 0x00000000, nsIInputStream * 0x044dd640, unsigned int 0, unsigned int 4684) line 1163 + 46 bytes nsStreamListenerTee::OnDataAvailable(nsStreamListenerTee * const 0x05276250, nsIRequest * 0x04fd8ba0, nsISupports * 0x00000000, nsIInputStream * 0x044de170, unsigned int 0, unsigned int 4684) line 56 + 51 bytes nsHTTPChunkConv::OnDataAvailable(nsHTTPChunkConv * const 0x00dfdfe8, nsIRequest * 0x04fd8ba0, nsISupports * 0x00000000, nsIInputStream * 0x05270f00, unsigned int 0, unsigned int 8644) line 211 + 46 bytes nsHTTPServerListener::OnDataAvailable(nsHTTPServerListener * const 0x05274b30, nsIRequest * 0x05275cf0, nsISupports * 0x04fd8ba0, nsIInputStream * 0x05270f00, unsigned int 142, unsigned int 8644) line 540 + 64 bytes nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x052752a0) line 161 + 70 bytes nsStreamObserverEvent::HandlePLEvent(PLEvent * 0x052752a4) line 79 PL_HandleEvent(PLEvent * 0x052752a4) line 588 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00576ab0) line 518 + 9 bytes _md_EventReceiverProc(HWND__ * 0x00300216, unsigned int 49357, unsigned int 0, long 5728944) line 1069 + 9 bytes USER32! 77e13eb0() USER32! 77e1401a() USER32! 77e192da() nsAppShellService::Run(nsAppShellService * const 0x0059d880) line 408 main1(int 2, char * * 0x004c5df0, nsISupports * 0x00000000) line 1021 + 32 bytes main(int 2, char * * 0x004c5df0) line 1316 + 37 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77e87903() Here's the assertion: nsresult nsCParserNode::ReleaseAll() { NS_ASSERTION(mTokenAllocator != nsnull, "aiee! no token allocator!"); if(mAttributes) { CToken* theAttrToken=0; while((theAttrToken=NS_STATIC_CAST(CToken*,mAttributes->Pop()))) { IF_FREE(theAttrToken, mTokenAllocator); } delete mAttributes; mAttributes=0; } if(mSkippedContent) { delete mSkippedContent; mSkippedContent=0; } IF_FREE(mToken, mTokenAllocator); return NS_OK; } I wind up hitting that assertion indefinately and have to kill the app. Why do we think this is "profile" related? I see the same problem whether I'm running a default/single profile, or a new one or whatever.
Attached file stack trace on Mac
the assertion death trap I was entering has been backed out. I still can't repro profile problems though.
has anyone reproduced this with a *mozilla* only build? brade, is that stack trace from a mozilla-only build?
Tracy, to be clear. You're not seeing this on linux or mac (indicated by your comments in 74728)? "verified fixed: windows 2001-04-04-12-trunk linux 2001-04-05-05-trunk mac 2001-04-05-04-trunk"
I can't reproduce this with a mozilla-only build. Looking for test coverage on those bits... tracy... can you try uninstalling the java plugin, and reinstall without it and see if this goes away?
I see this only on my Mac mozilla build. I do not see this on my Linux mozilla build. I do NOT see a problem if I remove my plugins folder.
yes, windows only Leaf, i'll try again with java excluded
using a commercial build on windows, I'm crashing on startup. if I remove the oji lib (NPOJI600.dll) from the plugins dir, I'm fine. changing summary from "crash in any profile management."
Summary: Crash in any profile managment → crash on startup w/ java plugin installed
If I were a betting man, I'd put some money on Xiaobin.Lu's checkins to fix up the nsIJVMManager API. I think these are basically expected to break OJI, though I'd have hoped that LiveConnect would cope more gracefully with a failure to get a VM.
the entire contents of my dir c:\program files\Mozilla.org\Mozilla\Plugins is: npjava11.dll, npjava12.dll, npjava32.dll, npnul32.dll
ben, your stack indicates you're seeing a different crash.
Judson, do my posts ( and attachment ) belong on a different bug?
ben, probably a good idea.
I don't have a valid stack trace on the crash, but just before the crash I'm seeing (Mac, mozilla build): Assertion failure: OBJ_GET_CLASS(cx, obj)->flags & JSCLASS_HAS_PRIVATE, at jsapi.c:1894 Assertion failure: OBJ_GET_CLASS(cx, obj)->flags & JSCLASS_HAS_PRIVATE, at jsapi.c:1894 stack crawl on the asserts (partial): 0A29CCC0 PPC 0E0874C8 nsJVMManager::InitLiveConnectClasses(JSContext*, JSObject*)+00020 0A29CC80 PPC 0E056910 JSJ_InitJSContext+0006C 0A29CC40 PPC 0E05E3E8 jsj_init_JavaClass+00068 0A29CBF0 PPC 0ECC9CF4 JS_InitClass+00148 0A29CB70 PPC 0ED15284 js_SetClassPrototype+000A0 0A29CB20 PPC 0E05D81C JavaClass_defineProperty+00024 0A29CAE0 PPC 0ECCA598 JS_GetPrivate+00144 0A29CA90 PPC 0ED43DD8 JS_Assert+00028 0A29CA50 PPC 0ED43D68 dprintf+00050
bnesse: do you see any message about not being able to load the JVM? I think LC is failing to spin up Java, and isn't handling that very well at all. Cc:ing edburns to see about making LiveConnect handle this situation more gracefully.
*** Bug 74854 has been marked as a duplicate of this bug. ***
No, I see no messages indicating that the JVM failed to load.
here's the crash stack. JS_PUBLIC_API(void *) JS_GetPrivate(JSContext * 0x02a9a690, JSObject * 0x00c1cce8) line 1894 + 267 bytes JavaClass_defineProperty(JSContext * 0x02a9a690, JSObject * 0x00c1cce8, long 24459376, long 12700912, int (JSContext *, JSObject *, long, long *)* 0x00000000, int (JSContext *, JSObject *, long, long *)* 0x00000000, unsigned int 0, JSProperty * * 0x00000000) line 340 + 14 bytes js_SetClassPrototype(JSContext * 0x02a9a690, JSObject * 0x00c1ccf0, JSObject * 0x00c1cce8, unsigned int 6) line 3042 + 44 bytes JS_InitClass(JSContext * 0x02a9a690, JSObject * 0x00c1b388, JSObject * 0x00000000, JSClass * 0x02b9a7f8 _JavaClass_class, int (JSContext *, JSObject *, unsigned int, long *, long *)* 0x02b87810 JavaClass_construct(JSContext *, JSObject *, unsigned int, long *, long *), unsigned int 0, JSPropertySpec * 0x00000000, JSFunctionSpec * 0x00000000, JSPropertySpec * 0x00000000, ...) line 1 jsj_init_JavaClass(JSContext * 0x02a9a690, JSObject * 0x00c1b388) line 737 + 36 bytes JSJ_InitJSContext(JSContext * 0x02a9a690, JSObject * 0x00c1b388, JavaPackageDef * 0x00000000) line 538 + 13 bytes nsJVMManager::InitLiveConnectClasses(nsJVMManager * const 0x02a78e38, JSContext * 0x02a9a690, JSObject * 0x00c1b388) line 362 + 15 bytes nsJSContext::InitializeLiveConnectClasses() line 1069 + 47 bytes nsJSContext::InitClasses(nsJSContext * const 0x02a9acd0) line 1269 + 246 bytes nsJSContext::InitContext(nsJSContext * const 0x02a9acd0, nsIScriptGlobalObject * 0x0180b2a0) line 1037 + 12 bytes NS_CreateScriptContext(nsIScriptGlobalObject * 0x0180b2a0, nsIScriptContext * * 0x017632b0) line 1556 nsDocShell::EnsureScriptEnvironment(nsDocShell * const 0x01763200) line 4429 + 50 bytes nsDocShell::GetScriptGlobalObject(nsDocShell * const 0x01763228, nsIScriptGlobalObject * * 0x0012f320) line 2461 + 19 bytes DocumentViewerImpl::Init(DocumentViewerImpl * const 0x02a74ef0, nsIWidget * 0x01764d14, nsIDeviceContext * 0x02a75cd0, const nsRect & {...}) line 646 + 56 bytes nsDocShell::SetupNewViewer(nsDocShell * const 0x01763200, nsIContentViewer * 0x02a74ef0) line 3019 + 66 bytes nsWebShell::SetupNewViewer(nsWebShell * const 0x01763200, nsIContentViewer * 0x02a74ef0) line 350 + 13 bytes nsDocShell::Embed(nsDocShell * const 0x01763220, nsIContentViewer * 0x02a74ef0, const char * 0x02271214, nsISupports * 0x00000000) line 2566 + 23 bytes nsWebShell::Embed(nsWebShell * const 0x01763220, nsIContentViewer * 0x02a74ef0, const char * 0x02271214, nsISupports * 0x00000000) line 379 nsDocShell::CreateContentViewer(nsDocShell * const 0x01763200, const char * 0x0012f718, nsIRequest * 0x017e3bf0, nsIStreamListener * * 0x0012f76c) line 2842 + 32 bytes nsDSURIContentListener::DoContent(nsDSURIContentListener * const 0x01762cb0, const char * 0x0012f718, int 0, const char * 0x100b60c8 gCommonEmptyBuffer, nsIRequest * 0x017e3bf0, nsIStreamListener * * 0x0012f76c, int * 0x0012f6fc) line 105 + 33 bytes nsDocumentOpenInfo::DispatchContent(nsIRequest * 0x017e3bf0, nsISupports * 0x00000000) line 370 + 109 bytes nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x017e2480, nsIRequest * 0x017e3bf0, nsISupports * 0x00000000) line 241 + 16 bytes nsJARChannel::OnStartRequest(nsJARChannel * const 0x017e3bf4, nsIRequest * 0x017e7254, nsISupports * 0x00000000) line 588 nsOnStartRequestEvent::HandleEvent(nsOnStartRequestEvent * const 0x017fbf10) line 125 + 47 bytes nsStreamObserverEvent::HandlePLEvent(PLEvent * 0x017fbf14) line 79 PL_HandleEvent(PLEvent * 0x017fbf14) line 588 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x0056fe50) line 518 + 9 bytes _md_EventReceiverProc(HWND__ * 0x001d0112, unsigned int 49357, unsigned int 0, long 5701200) line 1069 + 9 bytes USER32! 77e13eb0() USER32! 77e1401a() USER32! 77e192da() obj_get_class dies. JS_GetPrivate(JSContext *cx, JSObject *obj) { jsval v; JS_ASSERT(OBJ_GET_CLASS(cx, obj)->flags & JSCLASS_HAS_PRIVATE); v = OBJ_GET_SLOT(cx, obj, JSSLOT_PRIVATE); if (!JSVAL_IS_INT(v)) return NULL; return JSVAL_TO_PRIVATE(v); }
Let me rebuild my trunk and I'll investigate. My trunk is a week old.
Raghu, can you please try today's nightly mozilla build on a Win98 Machine and see if Java works?
Oddly enough Jud, your Windows crash stack is identical to my Mac assertion stack. I am, however, crashing beyond this point, well beyond as a matter of fact... looks like it's in the profile migration for me. Not that it still couldn't be JS related.
Cc: Xiaobin.Lu@eng.sun.co who checked in some Java-related stuff yesterday.
Shaver sez this is brendan
Assignee: valeski → brendan
It's brendan's change, I'm working on a fix. Gimme 10.
Assignee: brendan → shaver
I can't test it -- no Java installed here -- but I _think_ that should fix this. Please test for me. You just need to rebuild liveconnect.
Raju has tried nightly build with bundled 1.3.0_01 java Plugin java.sun.com java.sun.com/product/plugin/ Demonstration applets came up with no problems
Even with these 2 patches, I'm still crashing on window close, but only when the MJR plugin is installed. So you need a VM to see these crashes.
r/sr=brendan@mozilla.org -- sorry, none of us (shaver, jband, me) runs with Java installed and enabled. Time for me to start. /be
The patches eliminate the previous assetion failures and crashes and get me to a new browser window without crashing. I am now getting the follwing failure a number of times : Assetion failure: OBJ_IS_NATIVE(obj), at jslock.c:1048
Oops, shaver, I take it back -- sorry for the hasty sr. You do prevent a crash on startup, but if a JavaObject instance is created, we end up crashing while trying to finalize it, because js_FinalizeObject tries to getRequiredSlot, which goes through a JS_ASSERT(OBJ_IS_NATIVE(obj)) -- and as you just observed, these LiveConnect objects have ops such that they are not native. /be
Brendan wants to trade this bug for 12367, which was fixed by the not-native ploy. I'll attach a patch that should do that.
Thanks, that looks good. Please check in! /be
Fix is in.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Built trunk from 0200 today, confirmed that java works on win32.
verified on windows commercial build 2001-04-06-06-trunk
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: