280379 - Application crash when sending e-mail using web page - PresShell::DidDoReflow

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[Mike Calmus]

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

Comment 1

[Stephen Donner [:stephend] Not actively reading bugmail]

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...

Comment 2

[Mike Calmus]

I already tried it earlier today using a Trunk build I did myself. It is still
an issue. 

Comment 3

[Boris Zbarsky [:bzbarsky]]

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?

Comment 4

[Mike Calmus]

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

Comment 5

[Mike Calmus]

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

[Boris Zbarsky [:bzbarsky]]

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?

Comment 7

[Mike Calmus]

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.

Comment 8

[Mike Calmus]

Attachment: CrashReporter thread and stack trace

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

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

too late for 1.8b1, transferring request to 1.8b2

Comment 10

[Mike Calmus]

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

[Robert Kaiser]

Resolving as WFM, as reporter was the only one seeing it and says it doesn't
happen any more, clearing blocking flag