Closed Bug 14020 Opened 21 years ago Closed 21 years ago

Assertions about mDocWeak in password dialog

Categories

(Core :: XUL, defect, P1, blocker)

x86
Windows NT
defect

Tracking

()

VERIFIED DUPLICATE of bug 14164

People

(Reporter: scottputterman, Assigned: buster)

Details

Open mailnews.  Open a mail account.  Select an Inbox.  Do Get Msg.  Crash.

I'm assigning this to XPToolkit because I think you're doing window stuff.
cc'ing buster because the precondition is in Editor code.

First I get the following precondition

nsDebug::PreCondition(const char * 0x03eb45b8, const char * 0x03eb45ac, const
char * 0x03eb4580, int 294) line 163 + 13 bytes
nsEditor::GetDocument(nsEditor * const 0x03e3ef60, nsIDOMDocument * *
0x0012b348) line 294 + 41 bytes
nsHTMLEditor::~nsHTMLEditor() line 176
nsHTMLEditorLog::~nsHTMLEditorLog() line 47 + 22 bytes
nsHTMLEditorLog::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsEditor::Release(nsEditor * const 0x03e3ef60) line 178 + 102 bytes
nsHTMLEditor::Release(nsHTMLEditor * const 0x03e3ef60) line 211 + 12 bytes
nsHTMLEditorLog::Release(nsHTMLEditorLog * const 0x03e3ef60) line 50 + 12 bytes
nsCOMPtr<nsIEditor>::assign_with_AddRef(nsISupports * 0x00000000) line 633
nsCOMPtr<nsIEditor>::operator=(nsIEditor * 0x00000000) line 533
nsGfxTextControlFrame::~nsGfxTextControlFrame() line 246
nsGfxTextControlFrame::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsFrame::Destroy(nsFrame * const 0x03e3d470, nsIPresContext & {...}) line 317 +
34 bytes
nsFrameList::DestroyFrames(nsIPresContext & {...}) line 29
nsContainerFrame::Destroy(nsContainerFrame * const 0x02f6b080, nsIPresContext &
{...}) line 88
nsFrameList::DestroyFrame(nsIPresContext & {...}, nsIFrame * 0x02f6b080) line
115
nsBoxFrame::RemoveFrame(nsBoxFrame * const 0x02f69558, nsIPresContext & {...},
nsIPresShell & {...}, nsIAtom * 0x00000000 {???}, nsIFrame * 0x02f6b080) line
1388
FrameManager::RemoveFrame(FrameManager * const 0x03dcb9c0, nsIPresContext &
{...}, nsIPresShell & {...}, nsIFrame * 0x02f69558, nsIAtom * 0x00000000 {???},
nsIFrame * 0x02f6b080) line 381
nsCSSFrameConstructor::ContentRemoved(nsCSSFrameConstructor * const 0x03dcbea0,
nsIPresContext * 0x03dca9a0, nsIContent * 0x03e289f0, nsIContent * 0x03e2a330,
int 0) line 6137 + 58 bytes
nsCSSFrameConstructor::RecreateFramesForContent(nsIPresContext * 0x03dca9a0,
nsIContent * 0x03e2a330) line 7523 + 28 bytes
nsCSSFrameConstructor::AttributeChanged(nsCSSFrameConstructor * const
0x03dcbea0, nsIPresContext * 0x03dca9a0, nsIContent * 0x03e2a330, nsIAtom *
0x01377df0 {"style"}, int 2) line 6673 + 16 bytes
StyleSetImpl::AttributeChanged(StyleSetImpl * const 0x03dcbf40, nsIPresContext *
0x03dca9a0, nsIContent * 0x03e2a330, nsIAtom * 0x01377df0 {"style"}, int -1)
line 909
PresShell::AttributeChanged(PresShell * const 0x03dcbd98, nsIDocument *
0x03dc8be0, nsIContent * 0x03e2a330, nsIAtom * 0x01377df0 {"style"}, int -1)
line 1652 + 53 bytes
XULDocumentImpl::AttributeChanged(XULDocumentImpl * const 0x03dc8be0, nsIContent
* 0x03e2a330, nsIAtom * 0x01377df0 {"style"}, int -1) line 2155
RDFElementImpl::SetAttribute(RDFElementImpl * const 0x03e2a330, int 0, nsIAtom *
0x01377df0 {"style"}, const nsString & {"display: none;"}, int 1) line 2433
RDFElementImpl::SetAttribute(RDFElementImpl * const 0x03e2a320, const nsString &
{"style"}, const nsString & {"display: none;"}) line 1217 + 35 bytes
ElementSetAttribute(JSContext * 0x031bccc0, JSObject * 0x02e603d8, unsigned int
2, long * 0x02f57f34, long * 0x0012bc58) line 258 + 23 bytes
js_Invoke(JSContext * 0x031bccc0, unsigned int 2, unsigned int 0) line 654 + 26
bytes
js_Interpret(JSContext * 0x031bccc0, long * 0x0012c488) line 2228 + 15 bytes
js_Invoke(JSContext * 0x031bccc0, unsigned int 0, unsigned int 0) line 670 + 13
bytes

followed by a crash:

NTDLL! 77f76148()
nsWindow::Create(nsWindow * const 0x03f08ae4, nsIWidget * 0x00000000, const
nsRect & {x=0 y=0 width=0 height=0}, nsEventStatus (nsGUIEvent *)* 0x01f73b63
HandleEvent(nsGUIEvent *), nsIDeviceContext * 0x03ed69a0, nsIAppShell *
0x00000000, nsIToolkit * 0x00000000, nsWidgetInitData * 0x00000000) line 602
nsView::CreateWidget(nsView * const 0x03f08c20, const nsID & {...},
nsWidgetInitData * 0x00000000, void * 0x00000000, int 1) line 1234
DocumentViewerImpl::MakeWindow(void * 0x00000000, const nsRect & {x=0 y=0
width=0 height=0}, nsScrollPreference nsScrollPreference_kAuto) line 887 + 34
bytes
DocumentViewerImpl::Init(DocumentViewerImpl * const 0x03ee42d0, void *
0x00000000, nsIDeviceContext * 0x03ed69a0, nsIPref * 0x00ec76d0, const nsRect &
{x=0 y=0 width=0 height=0}, nsScrollPreference nsScrollPreference_kAuto) line
394
nsWebShell::Embed(nsWebShell * const 0x03ed50a0, nsIContentViewer * 0x03ee42d0,
const char * 0x03ed61c0, nsISupports * 0x00000000) line 867 + 69 bytes
nsDocumentBindInfo::OnStartRequest(nsDocumentBindInfo * const 0x03ed6200,
nsIChannel * 0x03ed7f70, nsISupports * 0x00000000) line 1887 + 36 bytes
nsChannelListener::OnStartRequest(nsChannelListener * const 0x03ed6140,
nsIChannel * 0x03ed7f70, nsISupports * 0x00000000) line 2225 + 43 bytes
nsInputStreamChannel::OnStartRequest(nsInputStreamChannel * const 0x03ed7f74,
nsIChannel * 0x03ed6060, nsISupports * 0x00000000) line 314
nsOnStartRequestEvent::HandleEvent(nsOnStartRequestEvent * const 0x03ed64c0)
line 207
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x03ed64c4) line 144 + 12 bytes
PL_HandleEvent(PLEvent * 0x03ed64c4) line 509 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x031b0560) line 470 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x0164086c, unsigned int 49410, unsigned int 0,
long 52102496) line 938 + 9 bytes
USER32! 77e71250()
031b0560()
Assignee: trudelle → danm
Priority: P3 → P1
Target Milestone: M11
This bit me twice this morning on Win98.  Dan, could you take a look at it?
setting P1 for M11.
Status: NEW → ASSIGNED
Whiteboard: problem more-or-less understood. looking for fix.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Whiteboard: problem more-or-less understood. looking for fix.
It's not really a crash -- at least on my machine, you can slog through the debug breaks until the password
dialog comes up.  It's really no worse than the assert in nsEditor:::GetDocument.  But anyway ...

The problem is an interaction between gfx editor widgets, which are webshells (!), and the onload handler
in the password dialog, which can hide editor widgets before they're completely initialized.  The surprised
Windows OS objects to the inevitable attempt to create a child window without a parent..  That's been fixed.

As for the assert in nsEditor::GetDocument which complains the editor hasn't yet been initialized, well,
it hasn't been.  The code can handle it, and the assertion is just noise in this case.  I vote we get rid of it.
Dan, I don't think this really just an assert. I repeatedly crash (NOT ASSERT)
when bringing up the password dialog. In addition Peter Trudelle sees it and
he's running a release build. (i.e. he crashes too).

I don't think we should take out the assert in nsEditor::GetDocument at all. It
was actually indicative of a very serious editor problem today. That's why we
started to see it.

The more I think about it, I think this bug was showing two problems:
1) The bug you just fixed involving the parent window
2) a problem in editor that Simon is about to check a fix in for very soon
involving netwerk & editor interaction.

Let's just let it represent (1) for now since editor team already has lots of
bugs on (2).

So (1)'s fixed and Simon's about to check in (2) soon.
Status: RESOLVED → REOPENED
Assignee: danm → buster
Status: REOPENED → NEW
OK, I'm hijacking this bug to represent the assertion seen in the editor when
the password dialog comes up:

nsDebug::PreCondition(const char * 0x03eb45b8, const char * 0x03eb45ac, const
char * 0x03eb4580, int 294) line 163 + 13 bytes
nsEditor::GetDocument(nsEditor * const 0x03e3ef60, nsIDOMDocument * *
0x0012b348) line 294 + 41 bytes
nsHTMLEditor::~nsHTMLEditor() line 176
nsHTMLEditorLog::~nsHTMLEditorLog() line 47 + 22 bytes
Resolution: FIXED → ---
Summary: Crash in password dialog → Assertions about mDocWeak in password dialog
OK, so this is the old problem of the document lifetime being shorter than that
of the editor, so that doc has gone away when the editor's dtor is called. Now
that we are using weak references, we just assert here.

Buster, I think you fixed something like this before.
Status: NEW → RESOLVED
Closed: 21 years ago21 years ago
Resolution: --- → DUPLICATE
*** This bug has been marked as a duplicate of 14164 ***
Status: RESOLVED → VERIFIED
duplicate bug is marked fixed and verified.  I'm going to mark this verified.
You need to log in before you can comment on or make changes to this bug.