If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

VERIFIED WORKSFORME

Status

SeaMonkey
MailNews: Address Book & Contacts
P3
major
VERIFIED WORKSFORME
18 years ago
13 years ago

People

(Reporter: Richard Zach, Assigned: Eric Vaughan)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+] 12/03/1999)

Attachments

(2 attachments)

(Reporter)

Description

18 years ago
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()

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M12

Updated

18 years ago
QA Contact: lchiang → esther

Comment 1

18 years ago
Created attachment 3097 [details]
Macsbug Stdlog of crash.

Comment 2

18 years ago
From the stdlog it looks like we are crashing in Reflow().  Peter, any
suggestions for an owner of this bug?
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.
Assignee: hangas → evaughan
Status: ASSIGNED → NEW
Summary: [CRASH][Regression] Crash when using the address picker → [DOGFOOD][CRASH][Regression] memory corruption / crash in nsBoxFrame::FlowChildren (when using the address picker in message compose)
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.

Updated

18 years ago
Whiteboard: [PDT+]

Comment 5

18 years ago
Putting on PDT+ radar.

Updated

18 years ago
OS: Linux → All
Hardware: PC → All

Comment 6

18 years ago
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

18 years ago
Created attachment 3102 [details] [diff] [review]
diff for this bug.
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.
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Whiteboard: [PDT+] → [PDT+] 12/03/1999
(Assignee)

Comment 9

18 years ago
*** This bug has been marked as a duplicate of 20161 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE

Updated

18 years ago
Status: RESOLVED → REOPENED

Updated

18 years ago
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: DUPLICATE → WORKSFORME

Updated

18 years ago
Status: RESOLVED → VERIFIED

Comment 10

18 years ago
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.
(Reporter)

Comment 11

18 years ago
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

18 years ago
zach: please file a new bug on this if you haven't already. copy-n-paste your
last statement there. thanks!!!
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.