Closed Bug 4933 Opened 26 years ago Closed 25 years ago

How to crash M4 build on startup

Categories

(Core Graveyard :: Tracking, defect, P2)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: morse, Assigned: morse)

Details

Using a fresh M4 build, I start the browser up from the debugger. While it is loading I hit alt-tab to switch to another window. I then get the following browser crash. NTDLL! 77f76148() nsDebug::PreCondition(char * 0x01b67a18, char * 0x01b67a08, char * 0x01b679d4, int 528) line 120 + 13 bytes nsBrowserAppCore::SetContentWindow(nsBrowserAppCore * const 0x01116f50, nsIDOMWindow * 0x00000000) line 528 + 32 bytes BrowserAppCoreSetContentWindow(JSContext * 0x00fd5350, JSObject * 0x01895310, unsigned int 1, long * 0x0189f9a0, long * 0x0012ec64) line 436 + 21 bytes js_Invoke(JSContext * 0x00fd5350, unsigned int 1, int 0) line 650 + 26 bytes js_Interpret(JSContext * 0x00fd5350, long * 0x0012f43c) line 2183 + 15 bytes js_Invoke(JSContext * 0x00fd5350, unsigned int 0, int 0) line 666 + 13 bytes js_Interpret(JSContext * 0x00fd5350, long * 0x0012fbb4) line 2183 + 15 bytes js_Execute(JSContext * 0x00fd5350, JSObject * 0x018676b0, JSScript * 0x01114310, JSFunction * 0x00000000, JSStackFrame * 0x00000000, int 0, long * 0x0012fbb4) line 815 + 13 bytes JS_EvaluateUCScriptForPrincipals(JSContext * 0x00fd5350, JSObject * 0x018676b0, JSPrincipals * 0x00000000, unsigned short * 0x01114ee0, unsigned int 9, char * 0x0134817c, unsigned int 0, long * 0x0012fbb4) line 2322 + 27 bytes nsJSContext::EvaluateString(nsJSContext * const 0x00fd5310, const nsString & {...}, char * 0x0134817c, unsigned int 0, nsString & {...}, int * 0x0012fbf0) line 122 + 64 bytes nsWebShellWindow::ExecuteJavaScriptString(nsString & {...}) line 1205 + 41 bytes nsWebShellWindow::ExecuteStartupCode() line 1235 nsWebShellWindow::OnEndDocumentLoad(nsWebShellWindow * const 0x00f96778, nsIURL * 0x00f97c70, int 0) line 885 nsWebShell::OnEndDocumentLoad(nsWebShell * const 0x00f96e90, nsIURL * 0x00f97c70, int 0) line 2211 nsDocLoaderImpl::FireOnEndDocumentLoad(int 0) line 1287 nsDocLoaderImpl::LoadURLComplete(nsIURL * 0x01143220, nsISupports * 0x011434a0, int 0) line 1445 nsDocumentBindInfo::OnStopBinding(nsDocumentBindInfo * const 0x011434a0, nsIURL * 0x01143220, unsigned int 0, unsigned short * 0x0114d6b0) line 2005 OnStopBindingProxyEvent::HandleEvent(OnStopBindingProxyEvent * const 0x0114d660) line 591 + 45 bytes StreamListenerProxyEvent::HandlePLEvent(PLEvent * 0x0114d664) line 471 + 12 bytes PL_HandleEvent(PLEvent * 0x0114d664) line 476 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00edf4c0) line 437 + 9 bytes _md_EventReceiverProc(void * 0x0012030a, unsigned int 49257, unsigned int 0, long 15594688) line 799 + 9 bytes US
Assignee: chofmann → don
don or peter?
Assignee: don → law
Priority: P3 → P2
Target Milestone: M5
Re-assigned to law@netscape.com, set target milestone to M5, and changed priority to P2. Bill, can you figure out who should get this bug? Is this an XPApps bug? Should we elevate this to P1?
Status: NEW → ASSIGNED
I think maybe I fixed this with changes I checked in last Friday (avoids calling setContentWindow with a null window pointer). I'd like to have the tester check out the current build (since this one looks tricky to replicate).
QA Contact: 3853 → 3849
morse or beppe (can you get a tester with debugger), can you try this again with Apr20 build. This may be fixed now.
I'm in the middle of some massive changes right now and don't want to pull a new tree. So, Beth, can you test this? If not, then assign it to me (to remind me) and when I next pull a tree I'll test this out.
Assignee: law → morse
Status: ASSIGNED → NEW
Re-assigned to morse.
With a tree that I pulled this moring, I no longer see this crash. So it got fixed with some change that somebody made. Closing it out as fixed.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
It might be fixed, or it might just be masked. I don't think we should mark bugs fixed unless a checkin was made with the intention of fixing them. This one should really be marked 'works for me', cuz that's all we know.
Status: RESOLVED → REOPENED
OK, works-for-me it is.
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: FIXED → WORKSFORME
Status: RESOLVED → VERIFIED
checked this on the optimized build too and it does not crash either, marking as verified.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.