Closed Bug 12142 Opened 25 years ago Closed 25 years ago

[QA BLOCKER] Crash when trying to bring up the mail compose window

Categories

(MailNews Core :: Composition, defect, P3)

Product:
MailNews Core
Component:
Composition
Platform:
All
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: mscott, Assigned: rods)

References

Details

I didn't see this problem with a tree pulled around midnight last night. I did
see it this morning. I looked at the build logs and Rod made changes to the
files that I see in my stack trace this morning so he looks like a good
candidate.

To see the problem:
Run messenger and hit New Message to bring up the compose window.

I repeatedly get stuck with an assertion with the following stack trace:
The pre condition string is: "not a container". I've tried continuing past the
assertion with no luck...it continually hits it. I'm marking this as a QA
blocker bug because you can't send mail!

nsDebug::PreCondition(const char * 0x01d10e68, const char * 0x01d10e5c, const
char * 0x01d10e30, int 267) line 152 + 13 bytes
nsFrame::AppendFrames(nsFrame * const 0x03e95a60, nsIPresContext & {...},
nsIPresShell & {...}, nsIAtom * 0x00000000 {???}, nsIFrame * 0x03f32a30) line
267 + 35 bytes
FrameManager::AppendFrames(FrameManager * const 0x03640f80, nsIPresContext &
{...}, nsIPresShell & {...}, nsIFrame * 0x03e95a60, nsIAtom * 0x00000000 {???},
nsIFrame * 0x03f32a30) line 354
nsCSSFrameConstructor::AppendFrames(nsIPresContext * 0x032dc0d0, nsIPresShell *
0x0363f3a0, nsIFrameManager * 0x03640f80, nsIContent * 0x03e41460, nsIFrame *
0x03e95a60, nsIFrame * 0x03f32a30) line 4260 + 30 bytes
nsCSSFrameConstructor::ContentAppended(nsCSSFrameConstructor * const 0x0363f490,
nsIPresContext * 0x032dc0d0, nsIContent * 0x03e41460, int 1) line 4358
StyleSetImpl::ContentAppended(StyleSetImpl * const 0x0363f530, nsIPresContext *
0x032dc0d0, nsIContent * 0x03e41460, int 1) line 790
PresShell::ContentAppended(PresShell * const 0x0363f3a8, nsIDocument *
0x032d8b20, nsIContent * 0x03e41460, int 1) line 1562 + 46 bytes
XULDocumentImpl::ContentAppended(XULDocumentImpl * const 0x032d8b20, nsIContent
* 0x03e41460, int 1) line 1962
nsGenericHTMLContainerElement::AppendChildTo(nsIContent * 0x03f32dac, int 1)
line 2778
nsGenericHTMLContainerElement::InsertBefore(nsIDOMNode * 0x03f32da0, nsIDOMNode
* 0x00000000, nsIDOMNode * * 0x0012d688) line 2462 + 14 bytes
nsGenericHTMLContainerElement::AppendChild(nsIDOMNode * 0x03f32da0, nsIDOMNode *
* 0x0012d688) line 2618
nsHTMLSelectElement::Add(nsHTMLSelectElement * const 0x03e41450,
nsIDOMHTMLElement * 0x03f32da0, nsIDOMHTMLElement * 0x00000000) line 310 + 19
bytes
HTMLSelectElementAdd(JSContext * 0x032dda30, JSObject * 0x03a26340, unsigned int
2, long * 0x030377e4, long * 0x0012d7d4) line 542 + 33 bytes
js_Invoke(JSContext * 0x032dda30, unsigned int 2, unsigned int 0) line 654 + 26
bytes
js_Interpret(JSContext * 0x032dda30, long * 0x0012e000) line 2228 + 15 bytes
js_Invoke(JSContext * 0x032dda30, unsigned int 0, unsigned int 0) line 670 + 13
bytes
js_Interpret(JSContext * 0x032dda30, long * 0x0012e7e8) line 2228 + 15 bytes
js_Invoke(JSContext * 0x032dda30, unsigned int 0, unsigned int 0) line 670 + 13
bytes
js_Interpret(JSContext * 0x032dda30, long * 0x0012efd0) line 2228 + 15 bytes
js_Invoke(JSContext * 0x032dda30, unsigned int 1, unsigned int 2) line 670 + 13
bytes
js_InternalCall(JSContext * 0x032dda30, JSObject * 0x02fa0ea8, long 49942192,
unsigned int 1, long * 0x0012f110, long * 0x0012f118) line 747 + 15 bytes
JS_CallFunctionValue(JSContext * 0x032dda30, JSObject * 0x02fa0ea8, long
49942192, unsigned int 1, long * 0x0012f110, long * 0x0012f118) line 2643 + 29
bytes
nsJSEventListener::HandleEvent(nsIDOMEvent * 0x03f210b0) line 97 + 34 bytes
nsEventListenerManager::HandleEvent(nsIPresContext & {...}, nsEvent *
0x0012f304, nsIDOMEvent * * 0x0012f2b0, unsigned int 3, nsEventStatus &
nsEventStatus_eIgnore) line 917 + 21 bytes
RDFElementImpl::HandleDOMEvent(RDFElementImpl * const 0x03dfa1b0, nsIPresContext
& {...}, nsEvent * 0x0012f304, nsIDOMEvent * * 0x0012f2b0, unsigned int 1,
nsEventStatus & nsEventStatus_eIgnore) line 2392
RDFElementImpl::ExecuteJSCode(nsIDOMElement * 0x03dfa1a0) line 2777
RDFElementImpl::ExecuteOnChangeHandler(nsIDOMElement * 0x03df2d30, const
nsString & {"ready"}) line 2700 + 14 bytes
RDFElementImpl::SetAttribute(RDFElementImpl * const 0x03dfa240, int 0, nsIAtom *
0x03dfba60 {"ready"}, const nsString & {"true"}, int 1) line 1998
RDFXULBuilderImpl::AddAttribute(nsIContent * 0x03dfa240, nsIRDFResource *
0x03dfad30, nsIRDFNode * 0x02ba48d0) line 2791 + 31 bytes
RDFXULBuilderImpl::OnChange(RDFXULBuilderImpl * const 0x03df1b04, nsIRDFResource
* 0x036c34a0, nsIRDFResource * 0x03dfad30, nsIRDFNode * 0x02b2a3b0, nsIRDFNode *
0x02ba48d0) line 1254 + 31 bytes
Adding Suresh to the cc list as I believe he was seeing a similar problem in
this mornings builds.
I take part of it back. There are about 15-18 assertions in the same spot. If I
skip past all of them, I do get a compose window.
This bug may need to go to Troy instead. I'm going to add him to the cc list.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
This is the same problem described in 12132

*** This bug has been marked as a duplicate of 12132 ***
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Seems it isn't a DUP after all. The other problem referred to get new mail and
not the new message window
Rod or Kevin, you guys are probably the best ones to fix this. Here's what is
happening.

Currently we're using nsNativeSelectControlFrame (so it seems). The mail code is
appending child nodes to the content model and that's causing us to build and
append frames to the select control frame

That's bad, because it's a leaf node and so we hit the assert in nsFrame's
AppendFrames() function

I added the assert recently, and that's probably why we haven't seen this
before.

Once we switch to gfx select form this won't be an issue. For the time being,
though, it's always been wrong I suppose that we're creating child frames for th
select frame. We should not do that. Either a rule in ua.css that indicates we
shouldn't, or we'll have to change ContentAppended() and ContentInserted() so
they check for those special tags that we don't create child frames for
Rod or Kevin, you guys are probably the best ones to fix this. Here's what is
happening.

Currently we're using nsNativeSelectControlFrame (so it seems). The mail code is
appending child nodes to the content model and that's causing us to build and
append frames to the select control frame

That's bad, because it's a leaf node and so we hit the assert in nsFrame's
AppendFrames() function

I added the assert recently, and that's probably why we haven't seen this
before.

Once we switch to gfx select form this won't be an issue. For the time being,
though, it's always been wrong I suppose that we're creating child frames for th
select frame. We should not do that. Either a rule in ua.css that indicates we
shouldn't, or we'll have to change ContentAppended() and ContentInserted() so
they check for those special tags that we don't create child frames for
*** Bug 12132 has been marked as a duplicate of this bug. ***
No, it does have to create a frame so layout knows how to size it correctly when
there are no items, but this is already being debated and doesn't really help
out here.

I am having zero luck getting mail or the compose window to even reach this
crash because I keep getting an assert in mork. Here is my crash dump, if
somebody gets me past this maybe I can debug the problem:

NTDLL! 77f76148()
nsDebug::Assertion(const char * 0x014b6c08, const char * 0x014b6b24, const char
* 0x014b6af4, int 74) line 176 + 13 bytes
mork_assertion_signal(const char * 0x014b6c08) line 74 + 31 bytes
morkEnv::NewError(const char * 0x02ab3210) line 362 + 19 bytes
morkFile::NewFileErrnoError(morkEnv * 0x02ab3760) line 264
morkStdioFile::new_stdio_file_fault(morkEnv * 0x02ab3760) line 660
morkStdioFile::OpenStdio(morkEnv * 0x02ab3760, const char * 0x02ab3bc8, const
char * 0x014b6e1c) line 731
morkStdioFile::morkStdioFile(morkEnv * 0x02ab3760, const morkUsage & {...},
nsIMdbHeap * 0x02ab37d0, nsIMdbHeap * 0x02ab37d0, const char * 0x02ab3bc8, const
char * 0x014b6e1c) line 685
morkStdioFile::CreateNewStdioFile(morkEnv * 0x02ab3760, nsIMdbHeap * 0x02ab37d0,
const char * 0x02ab3bc8) line 385 + 61 bytes
morkFile::CreateNewFile(morkEnv * 0x02ab3760, nsIMdbHeap * 0x02ab37d0, const
char * 0x02ab3bc8) line 183 + 17 bytes
morkStore::CreateStoreFile(morkEnv * 0x02ab3760, const char * 0x02ab3bc8, const
mdbOpenPolicy * 0x0012d4ec) line 674 + 20 bytes
orkinFactory::CreateNewFileStore(nsIMdbEnv * 0x02ab36c8, nsIMdbHeap *
0x02ab37d0, const char * 0x02ab3bc8, const mdbOpenPolicy * 0x0012d4ec,
nsIMdbStore * * 0x02ab3d1c) line 719 + 20 bytes
nsMsgFolderCache::OpenMDB(const char * 0x02ab3bc8, int 1) line 241 + 44 bytes
nsMsgFolderCache::Init(nsMsgFolderCache * const 0x02ab3d00, nsIFileSpec *
0x02ab3a60) line 269 + 23 bytes
nsMsgMailSession::Init() line 115
NS_NewMsgMailSession(const nsID & {...}, void * * 0x0012d8dc) line 271 + 8 bytes
nsMsgFactory::CreateInstance(nsMsgFactory * const 0x02ab1900, nsISupports *
0x00000000, const nsID & {...}, void * * 0x0012d8dc) line 220 + 13 bytes
nsComponentManagerImpl::CreateInstance(nsComponentManagerImpl * const
0x00a54e60, const nsID & {...}, nsISupports * 0x00000000, const nsID & {...},
void * * 0x0012d8dc) line 1399 + 24 bytes
nsComponentManager::CreateInstance(const nsID & {...}, nsISupports * 0x00000000,
const nsID & {...}, void * * 0x0012d8dc) line 78
nsServiceManagerImpl::GetService(nsServiceManagerImpl * const 0x00a519d0, const
nsID & {...}, const nsID & {...}, nsISupports * * 0x0012d97c,
nsIShutdownListener * 0x00000000) line 248 + 19 bytes
nsServiceManager::GetService(const nsID & {...}, const nsID & {...}, nsISupports
* * 0x0012d97c, nsIShutdownListener * 0x00000000) line 455
nsService::nsService(const nsID & {...}, const nsID & {...}, unsigned int *
0x0012d968) line 291 + 23 bytes
nsMsgFolderDataSource::Init() line 123 + 23 bytes
NS_NewMsgFolderDataSource(const nsID & {...}, void * * 0x0012da80) line 1156 +
11 bytes
nsMsgFactory::CreateInstance(nsMsgFactory * const 0x02ab19a0, nsISupports *
0x00000000, const nsID & {...}, void * * 0x0012da80) line 250 + 13 bytes
nsComponentManagerImpl::CreateInstance(nsComponentManagerImpl * const
0x00a54e60, const nsID & {...}, nsISupports * 0x00000000, const nsID & {...},
void * * 0x0012da80) line 1399 + 24 bytes
nsComponentManager::CreateInstance(const nsID & {...}, nsISupports * 0x00000000,
const nsID & {...}, void * * 0x0012da80) line 78
nsServiceManagerImpl::GetService(nsServiceManagerImpl * const 0x00a519d0, const
nsID & {...}, const nsID & {...}, nsISupports * * 0x0012dbbc,
nsIShutdownListener * 0x00000000) line 248 + 19 bytes
nsServiceManagerImpl::GetService(nsServiceManagerImpl * const 0x00a519d0, const
char * 0x0012dc00, const nsID & {...}, nsISupports * * 0x0012dbbc,
nsIShutdownListener * 0x00000000) line 393
I was always getting that problem, too, but now with the latest tree I'm okay.
When did you do a full pull?

I was hitting an assert in the profile manager, which was fixed when I deleted
the mozregistry.dat file
nsNativeSelectControlFrame looks like it's a leaf frame. Assuming it's not, then
it needs to implement AppendFrames() like the other container frames do
*** Bug 12132 has been marked as a duplicate of this bug. ***
Troy, thanks, deleting my mozregistry.dat did the trick. Now I can start to
debug.
Yes, Troy's suggestion of overriding AppendFrames in nsNativeSelectControlFrame
works, I'll check this in so others are unblocked.
I just checked in a temporary fix, this should work fine now. I overrode the
method AppendFrames in nsNativeSelectControlFrame.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Fixed
Linux RedHat 6.0 (1999-08-20-13 M10) Win_nt (1999-08-20-14 M10)
This problem does not exists any more.
Status: RESOLVED → VERIFIED
Using Mac build (1999-08-20-16 M10)
Crash problem when trying to bring up the mail message does not happen any more.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.