Closed Bug 12142 Opened 26 years ago Closed 26 years ago

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

Categories

(MailNews Core :: Composition, defect, P3)

All
Windows NT
defect

Tracking

(Not tracked)

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: 26 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: 26 years ago26 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.