Closed
Bug 4933
Opened 26 years ago
Closed 25 years ago
How to crash M4 build on startup
Categories
(Core Graveyard :: Tracking, defect, P2)
Tracking
(Not tracked)
VERIFIED
WORKSFORME
M5
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
Updated•26 years ago
|
Assignee: chofmann → don
Comment 1•26 years ago
|
||
don or peter?
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?
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).
morse or beppe (can you get a tester with debugger), can you try this again with
Apr20 build. This may be fixed now.
Assignee | ||
Comment 5•25 years ago
|
||
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 | ||
Comment 7•25 years ago
|
||
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
Comment 8•25 years ago
|
||
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.
Assignee | ||
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Assignee | ||
Comment 9•25 years ago
|
||
OK, works-for-me it is.
Assignee | ||
Updated•25 years ago
|
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: FIXED → WORKSFORME
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 10•25 years ago
|
||
checked this on the optimized build too and it does not crash either, marking as
verified.
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•