Closed Bug 280379 Opened 15 years ago Closed 15 years ago

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


(SeaMonkey :: General, defect, critical)

Not set


(Not tracked)



(Reporter: mike, Unassigned)




(Keywords: regression)


(1 file)

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

Talkback ID: TB3222364W, TB3242489X, TB3336426W
Depends on: 244366
Keywords: regression
Flags: blocking1.8b?
[/builds/release/trunk/mozilla/xpfe/appshell/src/nsContentTreeOwner.cpp, line 557]
_XPTC_InvokeByIndex()   XPC_WN_GetterSetter() 
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]
[/builds/release/trunk/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line
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]
[/builds/release/trunk/mozilla/js/src/jsapi.c, line 3741]
[/builds/release/trunk/mozilla/dom/src/base/nsJSEnvironment.cpp, line 141]
[/builds/release/trunk/mozilla/content/base/src/nsScriptLoader.cpp, line 715]
[/builds/release/trunk/mozilla/content/base/src/nsScriptLoader.cpp, line 622]
[/builds/release/trunk/mozilla/content/base/src/nsScriptLoader.cpp, line 1034]
line 653]
[/builds/release/trunk/mozilla/content/base/src/nsGenericElement.cpp, line 2593]
line 830]
line 3116]
line 3067]
[/builds/release/trunk/mozilla/parser/htmlparser/src/CNavDTD.cpp, line 3622]
[/builds/release/trunk/mozilla/parser/htmlparser/src/CNavDTD.cpp, line 1640]
[/builds/release/trunk/mozilla/parser/htmlparser/src/CNavDTD.cpp, line 904]
[/builds/release/trunk/mozilla/parser/htmlparser/src/CNavDTD.cpp, line 467]
[/builds/release/trunk/mozilla/parser/htmlparser/src/nsParser.cpp, line 842]
[/builds/release/trunk/mozilla/parser/htmlparser/src/nsParser.cpp, line 1892]
[/builds/release/trunk/mozilla/parser/htmlparser/src/nsParser.cpp, line 1428]
[/builds/release/trunk/mozilla/content/base/src/nsContentSink.cpp, line 284]
[/builds/release/trunk/mozilla/content/base/src/nsContentSink.cpp, line 848]
[/builds/release/trunk/mozilla/content/base/src/nsScriptLoader.cpp, line 652]
[/builds/release/trunk/mozilla/content/base/src/nsScriptLoader.cpp, line 59]
[/builds/release/trunk/mozilla/content/base/src/nsScriptLoader.cpp, line 965]
[/builds/release/trunk/mozilla/netwerk/base/src/nsStreamLoader.cpp, line 713]
[/builds/release/trunk/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp, line
[/builds/release/trunk/mozilla/netwerk/base/src/nsInputStreamPump.cpp, line 713]
[/builds/release/trunk/mozilla/netwerk/base/src/nsInputStreamPump.cpp, line 343]
PL_HandleEvent()  [/builds/release/trunk/mozilla/xpcom/threads/plevent.c, line 699]
[/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)
[/builds/release/trunk/mozilla/widget/src/mac/nsMacMessagePump.cpp, line 384]
[/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...
I already tried it earlier today using a Trunk build I did myself. It is still
an issue. 
Blocks: 244366
No longer depends on: 244366
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?
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         0x927d1fa0 DispatchEventToHandlers + 0x150
11         0x927d2214 SendEventToEventTargetInternal + 0x174
12         0x927d6694 SendEventToEventTargetWithOptions + 0x28
13         0x927e2d2c
ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*,
void*) + 0x2b8
14         0x927d205c DispatchEventToHandlers + 0x20c
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?
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

Also, what exact assert failures do you see?
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.

This crash report was from before I started making changes to the file. I have
others relating to various changes I made as well.
too late for 1.8b1, transferring request to 1.8b2
Flags: blocking1.8b?
Flags: blocking1.8b2?
Flags: blocking1.8b-
Flags: blocking-seamonkey1.0a?
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.
Resolving as WFM, as reporter was the only one seeing it and says it doesn't
happen any more, clearing blocking flag
Closed: 15 years ago
Flags: blocking-seamonkey1.0a?
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.