Closed
Bug 280379
Opened 20 years ago
Closed 20 years ago
Application crash when sending e-mail using web page - PresShell::DidDoReflow
Categories
(SeaMonkey :: General, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: mike, Unassigned)
References
()
Details
(Keywords: regression)
Attachments
(1 file)
(deleted),
text/plain
|
Details |
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b) Gecko/20050122 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b) Gecko/20050122 Using nightly builds after the patch for bug #244366 was checked in on 1/20, Mozilla crashes every time I go to http://mailcenter.comcast.net and send an e-mail. I have created a test account (userid/password: bugzilla1/bugzilla1) so users can check this themselves. This bug may be related to or the same as Bug #267863, Bug #271461 and Bug #271615. Reproducible: Always Steps to Reproduce: 1. Go to http://mailcenter.comcast.net 2. When redirected to main site, repeat step 1. 3. Log in 4. Choose Compose Message 5. Type any message and click Send. Actual Results: Crash Talkback ID: TB3222364W, TB3242489X, TB3336426W
Reporter | ||
Updated•20 years ago
|
Depends on: 244366
Keywords: regression
Reporter | ||
Updated•20 years ago
|
Flags: blocking1.8b?
Comment 1•20 years ago
|
||
nsContentTreeOwner::SetEnabled() [/builds/release/trunk/mozilla/xpfe/appshell/src/nsContentTreeOwner.cpp, line 557] _XPTC_InvokeByIndex() XPC_WN_GetterSetter() [/builds/release/trunk/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1312] js_Invoke() [/builds/release/trunk/mozilla/js/src/jsinterp.c, line 1293] js_InternalInvoke() [/builds/release/trunk/mozilla/js/src/jsinterp.c, line 1391] js_InternalGetOrSet() [/builds/release/trunk/mozilla/js/src/jsinterp.c, line 1434] js_SetProperty() [/builds/release/trunk/mozilla/js/src/jsobj.c, line 2936] js_Interpret() [/builds/release/trunk/mozilla/js/src/jsinterp.c, line 3407] js_Invoke() [/builds/release/trunk/mozilla/js/src/jsinterp.c, line 1313] nsXPCWrappedJSClass::CallMethod() [/builds/release/trunk/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1341] PrepareAndDispatch() [/builds/release/trunk/mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_ppc_rhapsody.cpp, line 234] SharedStub() jsds_ExecutionHookProc() [/builds/release/trunk/mozilla/js/jsd/jsd_xpc.cpp, line 713] jsd_CallExecutionHook() [/builds/release/trunk/mozilla/js/jsd/jsd_hook.c, line 178] JS_HandleTrap() [/builds/release/trunk/mozilla/js/src/jsdbgapi.c, line 213] js_Interpret() [/builds/release/trunk/mozilla/js/src/jsinterp.c, line 4073] js_Execute() [/builds/release/trunk/mozilla/js/src/jsinterp.c, line 1526] JS_EvaluateUCScriptForPrincipals() [/builds/release/trunk/mozilla/js/src/jsapi.c, line 3741] nsJSContext::EvaluateString() [/builds/release/trunk/mozilla/dom/src/base/nsJSEnvironment.cpp, line 141] nsScriptLoader::EvaluateScript() [/builds/release/trunk/mozilla/content/base/src/nsScriptLoader.cpp, line 715] nsScriptLoader::ProcessRequest() [/builds/release/trunk/mozilla/content/base/src/nsScriptLoader.cpp, line 622] nsScriptLoader::ProcessScriptElement() [/builds/release/trunk/mozilla/content/base/src/nsScriptLoader.cpp, line 1034] nsHTMLScriptElement::MaybeProcessScript() [/builds/release/trunk/mozilla/content/html/content/src/nsHTMLScriptElement.cpp, line 653] nsGenericElement::AppendChildTo() [/builds/release/trunk/mozilla/content/base/src/nsGenericElement.cpp, line 2593] HTMLContentSink::ProcessSCRIPTTag() [/builds/release/trunk/mozilla/content/html/document/src/nsHTMLContentSink.cpp, line 830] HTMLContentSink::AddLeaf() [/builds/release/trunk/mozilla/content/html/document/src/nsHTMLContentSink.cpp, line 3116] HTMLContentSink::AddHeadContent() [/builds/release/trunk/mozilla/content/html/document/src/nsHTMLContentSink.cpp, line 3067] CNavDTD::AddHeadLeaf() [/builds/release/trunk/mozilla/parser/htmlparser/src/CNavDTD.cpp, line 3622] CNavDTD::HandleStartToken() [/builds/release/trunk/mozilla/parser/htmlparser/src/CNavDTD.cpp, line 1640] CNavDTD::HandleToken() [/builds/release/trunk/mozilla/parser/htmlparser/src/CNavDTD.cpp, line 904] CNavDTD::BuildModel() [/builds/release/trunk/mozilla/parser/htmlparser/src/CNavDTD.cpp, line 467] nsParser::BuildModel() [/builds/release/trunk/mozilla/parser/htmlparser/src/nsParser.cpp, line 842] nsParser::ResumeParse() [/builds/release/trunk/mozilla/parser/htmlparser/src/nsParser.cpp, line 1892] nsParser::ContinueParsing() [/builds/release/trunk/mozilla/parser/htmlparser/src/nsParser.cpp, line 1428] nsContentSink::ScriptEvaluated() [/builds/release/trunk/mozilla/content/base/src/nsContentSink.cpp, line 284] nsScriptLoaderObserverProxy::ScriptEvaluated() [/builds/release/trunk/mozilla/content/base/src/nsContentSink.cpp, line 848] nsScriptLoader::FireScriptEvaluated() [/builds/release/trunk/mozilla/content/base/src/nsScriptLoader.cpp, line 652] nsScriptLoader::ProcessRequest() [/builds/release/trunk/mozilla/content/base/src/nsScriptLoader.cpp, line 59] nsScriptLoader::OnStreamComplete() [/builds/release/trunk/mozilla/content/base/src/nsScriptLoader.cpp, line 965] nsStreamLoader::OnStopRequest() [/builds/release/trunk/mozilla/netwerk/base/src/nsStreamLoader.cpp, line 713] nsHttpChannel::OnStopRequest() [/builds/release/trunk/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp, line 713] nsInputStreamPump::OnStateStop() [/builds/release/trunk/mozilla/netwerk/base/src/nsInputStreamPump.cpp, line 713] nsInputStreamPump::OnInputStreamReady() [/builds/release/trunk/mozilla/netwerk/base/src/nsInputStreamPump.cpp, line 343] nsInputStreamReadyEvent::EventHandler() PL_HandleEvent() [/builds/release/trunk/mozilla/xpcom/threads/plevent.c, line 699] PL_ProcessPendingEvents() [/builds/release/trunk/mozilla/xpcom/threads/plevent.c, line 633] _md_EventReceiverProc() [/builds/release/trunk/mozilla/xpcom/threads/plevent.c, line 1643] HIToolbox.145.0.0 + 0x1fa0 (0x927d1fa0) HIToolbox.145.0.0 + 0x2214 (0x927d2214) HIToolbox.145.0.0 + 0x6694 (0x927d6694) HIToolbox.145.0.0 + 0x12d2c (0x927e2d2c) HIToolbox.145.0.0 + 0x205c (0x927d205c) HIToolbox.145.0.0 + 0x2214 (0x927d2214) HIToolbox.145.0.0 + 0x146bc (0x927e46bc) HIToolbox.145.0.0 + 0x185d8 (0x927e85d8) HIToolbox.145.0.0 + 0x28718 (0x927f8718) HIToolbox.145.0.0 + 0x8d88 (0x927d8d88) HIToolbox.145.0.0 + 0x8f3c (0x927d8f3c) HIToolbox.145.0.0 + 0x1c9f0 (0x927ec9f0) HIToolbox.145.0.0 + 0x2d708 (0x927fd708) nsMacMessagePump::GetEvent() [/builds/release/trunk/mozilla/widget/src/mac/nsMacMessagePump.cpp, line 384] nsMacMessagePump::DoMessagePump() [/builds/release/trunk/mozilla/widget/src/mac/nsMacMessagePump.cpp, line 289] nsAppShell::Run() [/builds/release/trunk/mozilla/widget/src/mac/nsAppShell.cpp, line 114] mozilla-bin + 0xb088 (0x0000b088) mozilla-bin + 0xb5dc (0x0000b5dc) mozilla-bin + 0x8874 (0x00008874) mozilla-bin + 0x86f4 (0x000086f4) Can you try a later build? Several crash bugs have been fixed since your 1-22 build. Also, this worksforme using build 2005-01-29-05, but I tested on Windows XP, so I'm allowing for OS differences...
Reporter | ||
Comment 2•20 years ago
|
||
I already tried it earlier today using a Trunk build I did myself. It is still an issue.
Updated•20 years ago
|
Comment 3•20 years ago
|
||
Hmm... I can't reproduce this on Linux either (just sent 3 mails through that interface with no problems), and the three talkbacks in comment 0 have three totally different stacks. Mike, do you have time to help debug this, by any chance? And a debug build of Mozilla on hand? Or at least an opt build that you're willing to make trial changes to?
Reporter | ||
Comment 4•20 years ago
|
||
I have a debug build available. Just let me know what to try. I realize the crash location has changed. The latest crash dump I have (generated by the OS) is (in part) here: Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x7463685c Thread 0 Crashed: 0 <<00000000>> 0x7463685c 0 + 0x7463685c 1 libgklayout.dylib 0x0204c468 PresShell::DidDoReflow() + 0x20 2 libgklayout.dylib 0x0204c75c PresShell::ProcessReflowCommands(int) + 0x29c 3 libgklayout.dylib 0x0204c0e0 PresShell::WillPaint() + 0x4c 4 libgklayout.dylib 0x022939d8 nsViewManager::FlushPendingInvalidates() + 0xb0 5 libgklayout.dylib 0x02293a50 nsViewManager::ProcessInvalidateEvent() + 0x18 6 libgklayout.dylib 0x0228b074 HandlePLEvent(PLEvent*) + 0x50 7 libxpcom_core.dylib 0x003322c4 PL_HandleEvent + 0x24 8 libxpcom_core.dylib 0x003321e8 PL_ProcessPendingEvents + 0x80 9 libxpcom_core.dylib 0x003326cc _md_EventReceiverProc + 0x74 10 com.apple.HIToolbox 0x927d1fa0 DispatchEventToHandlers + 0x150 11 com.apple.HIToolbox 0x927d2214 SendEventToEventTargetInternal + 0x174 12 com.apple.HIToolbox 0x927d6694 SendEventToEventTargetWithOptions + 0x28 13 com.apple.HIToolbox 0x927e2d2c ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 0x2b8 14 com.apple.HIToolbox 0x927d205c DispatchEventToHandlers + 0x20c
Reporter | ||
Comment 5•20 years ago
|
||
The crash has been happening in the HandlePostedAttributeChanges method of layout/base/nsPresShell.cpp on the call to node->content->UnsetAttr(node->nameSpaceID, node->name, node->notify); I am also seeing some assert failures in the destructor, specifically in that both mFirstAttributeRequest and mLastAttributeRequest are not null. If I set them to null in that method, the crash does not occur at that spot but does so later on in a call to WillPaint(). The crash log indicates the crash should be on the call to mViewManager->EndUpdateViewBatch in that case, but I'm having a hard time debugging it fully. I'm also seeing some messages about the "Deallocation of a pointer not malloced" which I believe is related to the root cause. I'm having a hard time figuring out exactly where a fix can be applied since there seems to be a timer firing inside this class. Can we get another Mac user to confirm and/or look at this?
Comment 6•20 years ago
|
||
Yikes. I thought I cced myself on this.... Mike, could you either attach or mail me a full backtrace with details about what the locals look like when we actually crash? In particular, what is node->content? Also, what exact assert failures do you see?
Reporter | ||
Comment 7•20 years ago
|
||
Here's the assertion and warning I see: ###!!! ASSERTION: post-reflow queues not empty. This means we're leaking: 'mFirstDOMEventRequest == nsnull && mLastDOMEventRequest == nsnull && mFirstAttributeRequest == nsnull && mLastAttributeRequest == nsnull && mFirstCallbackEventRequest == nsnull && mLastCallbackEventRequest == nsnull', file nsPresShell.cpp, line 1645 Break: at file nsPresShell.cpp, line 1645 ^G*** malloc[29708]: Deallocation of a pointer not malloced: 0x29edb350; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug I'll be attaching a crash log shortly. As for the value of node->content, I believe that is at least part of the problem. I think the pointer at the point of the crash is invalid. When I null out mFirstAttributeRequest at the point of the assertion failure above, the crash no longer happens in HandlePostedAttributeChanges. Also, when I tried to print parts of node to the console, it crashed at that point rather than the one expected. I can do more checking this evening if you need more specifics.
Reporter | ||
Comment 8•20 years ago
|
||
This crash report was from before I started making changes to the file. I have others relating to various changes I made as well.
Comment 9•20 years ago
|
||
too late for 1.8b1, transferring request to 1.8b2
Flags: blocking1.8b?
Flags: blocking1.8b2?
Flags: blocking1.8b-
Updated•20 years ago
|
Flags: blocking-seamonkey1.0a?
Reporter | ||
Comment 10•20 years ago
|
||
This seems now to be working both in a SeaMonkey and in a Firefox Trunk build. If anybody cares I can try to find which code change fixed it. Otherwise, mark it however is appropriate.
Comment 11•20 years ago
|
||
Resolving as WFM, as reporter was the only one seeing it and says it doesn't happen any more, clearing blocking flag
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Flags: blocking-seamonkey1.0a?
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•