20237 - [DOGFOOD][CRASH][Regression] memory corruption / crash in nsBoxFrame::FlowChildren (when using the address picker in message compose)

Status: VERIFIED WORKSFORME

(SeaMonkey :: MailNews: Address Book & Contacts, defect, P3)

Description

[Richard Zach]

Using the address picker to choose a recipient crashes Mozilla.

To reproduce:
1. Open Messenger
2. Click New Msg
3. Click Address

Actual behavior: Crash
Expected behavior: The address picker window appears

This on Linux build 1999.11.28.08 running on RH 6.0; works fine on 1999.11.15
M11.  Doesn't make a difference whether and which mail folder is open.

Console output:
...
Created editorShell
editor initialized in HTML mode
Attaching to WebShellWindow[_blank]
set focus on the recipient
toAddress:
we don't handle eBorderStyle_close yet... please fix me
nsXULKeyListenerImpl::Init()

Comment 1

[hangas]

Attachment: Macsbug Stdlog of crash.

Comment 2

[hangas]

From the stdlog it looks like we are crashing in Reflow().  Peter, any
suggestions for an owner of this bug?

Comment 3

[(not reading, please use [e-mail] instead)]

adding waterson to the cc list.

note, I'm not seeing this on my windows and linux mozilla builds from 11-29099
from about 10 am.

Comment 4

[(not reading, please use [e-mail] instead)]

from putterman:

I can ignore this on Windows (though I don't know for how long).  It's a memory
corruption at:

_free_dbg_lk(void * 0x03bd7a40, int 1) line 1033 + 60 bytes
_free_dbg(void * 0x03bd7a40, int 1) line 970 + 13 bytes
operator delete(void * 0x03bd7a40) line 49 + 16 bytes
nsBoxFrame::FlowChildren(nsIPresContext * 0x03cee430, nsHTMLReflowMetrics &
{...}, const nsHTMLReflowState & {...}, unsigned int & 0,
nsRect & {x=15 y=0 width=5710 height=6302}) line 729 + 24 bytes
nsBoxFrame::Reflow(nsBoxFrame * const 0x03bc65b0, nsIPresContext * 0x03cee430,
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState &
{...}, unsigned int & 0) line 593
nsBoxFrame::FlowChildAt(nsIFrame * 0x03bc65b0, nsIPresContext * 0x03cee430,
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState &
{...}, unsigned int & 0, nsCalculatedBoxInfo & {...}, int & 1, nsString &
{"child's width got bigger"}) line 1153
nsBoxFrame::FlowChildren(nsIPresContext * 0x03cee430, nsHTMLReflowMetrics &
{...}, const nsHTMLReflowState & {...}, unsigned int & 0,
nsRect & {x=0 y=15 width=8515 height=6304}) line 694
nsBoxFrame::Reflow(nsBoxFrame * const 0x03bc1740, nsIPresContext * 0x03cee430,
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState &
{...}, unsigned int & 0) line 593
nsBoxFrame::FlowChildAt(nsIFrame * 0x03bc1740, nsIPresContext * 0x03cee430,
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState &
{...}, unsigned int & 0, nsCalculatedBoxInfo & {...}, int & 0, nsString &
{"initial"}) line 1153
nsBoxFrame::FlowChildren(nsIPresContext * 0x03cee430, nsHTMLReflowMetrics &
{...}, const nsHTMLReflowState & {...}, unsigned int & 0,
nsRect & {x=0 y=0 width=9600 height=6334}) line 694
nsBoxFrame::Reflow(nsBoxFrame * const 0x03bc1ce0, nsIPresContext * 0x03cee430,
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState &
{...}, unsigned int & 0) line 593
nsBoxFrame::FlowChildAt(nsIFrame * 0x03bc1ce0, nsIPresContext * 0x03cee430,
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState &
{...}, unsigned int & 0, nsCalculatedBoxInfo & {...}, int & 1, nsString &
{"initial"}) line 1153
nsBoxFrame::FlowChildren(nsIPresContext * 0x03cee430, nsHTMLReflowMetrics &
{...}, const nsHTMLReflowState & {...}, unsigned int & 0,
nsRect & {x=0 y=0 width=9600 height=7199}) line 694
nsBoxFrame::Reflow(nsBoxFrame * const 0x03c5c710, nsIPresContext * 0x03cee430,
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState &
{...}, unsigned int & 0) line 593
nsContainerFrame::ReflowChild(nsIFrame * 0x03c5c710, nsIPresContext *
0x03cee430, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState
& {...}, int 0, int 0, unsigned int 0, unsigned int & 0) line 639 + 31 bytes
RootFrame::Reflow(RootFrame * const 0x03c5b600, nsIPresContext * 0x03cee430,
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState &
{...}, unsigned int & 0) line 333
nsContainerFrame::ReflowChild(nsIFrame * 0x03c5b600, nsIPresContext *
0x03cee430, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState
& {...}, int 0, int 0, unsigned int 0, unsigned int & 0) line 639 + 31 bytes
ViewportFrame::Reflow(ViewportFrame * const 0x03c5b930, nsIPresContext *
0x03cee430, nsHTMLReflowMetrics & {...}, const
nsHTMLReflowState & {...}, unsigned int & 0) line 527
PresShell::InitialReflow(PresShell * const 0x03ceaea0, int 9600, int 7200) line
1003
nsXULDocument::StartLayout() line 3391
nsXULDocument::ResumeWalk() line 4689
nsXULDocument::OnUnicharStreamComplete(nsXULDocument * const 0x03cef824,
nsIUnicharStreamLoader * 0x00000000, unsigned int 0, const
unsigned short * 0x034b0db0) line 4811 + 11 bytes
nsUnicharStreamLoader::OnStopRequest(nsUnicharStreamLoader * const 0x03be3534,
nsIChannel * 0x03be5760, nsISupports * 0x00000000,
unsigned int 0, const unsigned short * 0x00000000) line 125 + 50 bytes
nsChannelListener::OnStopRequest(nsChannelListener * const 0x03be5050,
nsIChannel * 0x03be5760, nsISupports * 0x00000000, unsigned int 0,
const unsigned short * 0x00000000) line 1558
nsFileChannel::OnStopRequest(nsFileChannel * const 0x03be5764, nsIChannel *
0x03be57e0, nsISupports * 0x00000000, unsigned int 0, const
unsigned short * 0x00000000) line 474 + 45 bytes
nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x03be53f0) line
326
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x03be1fd0) line 173 + 12 bytes
PL_HandleEvent(PLEvent * 0x03be1fd0) line 537 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x03cfd320) line 498 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x001a14d2, unsigned int 49479, unsigned int 0,
long 63951648) line 972 + 9 bytes
USER32! 77e71820()
03cfd320()

that matches the stack from hangas's attachment.

re-assign to evaughan

updating summary.

note, I'm not seeing this, but putterman and hangas are.

marking dogfood.

Comment 5

[leger]

Putting on PDT+ radar.

Comment 6

[scottputterman]

Seth and I looked at this and I will attach a diff that works.  Basically, the
resized array wasn't being reallocated if GetNextCreateIfNeeded added a new
element and therefore in ChildResized, the resized array was being accessed
written to passed the array boundaries.

This fix isn't pretty so you may want to make it look nicer.  Or you may know
something we don't know about the size of the array.  Anyway, we start off by
allocating twice as much space as is needed so that the copy operation later on
doesn't happen often (in our test run it never happened). And then after a new
item is added, we reallocate the array to make it bigger and copy over the old
items.

Comment 7

[scottputterman]

Attachment: diff for this bug.

Comment 8

[(not reading, please use [e-mail] instead)]

and now for some humble pie...

I wasn't seeing it because I wasn't doing the right thing to reproduce it.

my, that tastes good.

Comment 9

[Eric Vaughan]

*** This bug has been marked as a duplicate of 20161 ***

Comment 10

[esther]

Not sure if this is a duplicate of 20161.  With builds 1999120109m12 on win98
and linux and build 19991201m12 on mac the original scenario as stated above
works OK.  On Win98 the duplicate bug scenario works on win98, but crashes on
mac and linux.  Changing resolve from duplicate to worksforme.

Comment 11

[Richard Zach]

The following happens for me now (1999.12.02.08 Linux build):

1. Open compose window
2. Open address picker
3. Close address picker (doesn't matter if address picked or not)
4. Close compose window by clicking close box, or File|Close

Is this a known bug?
Actual results: compose widow goes blank.  Forcibly destroy compose window, and
Mozilla crashes.  Sometimes, it crashes on it's own.

Expected results: compose window closes

Comment 12

[Chris Waterson]

zach: please file a new bug on this if you haven't already. copy-n-paste your
last statement there. thanks!!!