Closed
Bug 20591
Opened 26 years ago
Closed 26 years ago
Dogfood: memory corruption in box layout
Categories
(Core :: XUL, defect, P1)
Tracking
()
VERIFIED
FIXED
M12
People
(Reporter: buster, Assigned: cmaximus)
Details
(Whiteboard: [PDT+] 12/3/1999 DEC-9 awaiting feedback)
1. open mozilla.exe
2. New > Message
3. Click on the "address" button
on WinNT with a debug build, I get a memory corruption dialog. It says:
Debug Error!
Program s:\mozilla\dist\win32_d.obj\mozilla.exe
DAMAGE: after Normal block (#225188) at 0x02F3E850
(Press Retry to debug the application)
Pressing Retry gets you into the debugger at this line:
delete[] resized;
It's almost certainly an array bounds over/underflow.
Here's the stack:
_free_dbg_lk(void * 0x030e8600, int 1) line 1033 + 60 bytes
_free_dbg(void * 0x030e8600, int 1) line 970 + 13 bytes
operator delete(void * 0x030e8600) line 49 + 16 bytes
nsBoxFrame::FlowChildren(nsIPresContext * 0x0304c680, nsHTMLReflowMetrics &
{...}, const nsHTMLReflowState & {...}, unsigned int & 0, nsRect & {x=15 y=0
width=5710 height=6302}) line 729 + 24 bytes
nsBoxFrame::Reflow(nsBoxFrame * const 0x030c3180, nsIPresContext * 0x0304c680,
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 593
nsBoxFrame::FlowChildAt(nsIFrame * 0x030c3180, nsIPresContext * 0x0304c680,
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0,
nsCalculatedBoxInfo & {...}, int & 1, nsString & {"child's width got bigger"})
line 1153
nsBoxFrame::FlowChildren(nsIPresContext * 0x0304c680, nsHTMLReflowMetrics &
{...}, const nsHTMLReflowState & {...}, unsigned int & 0, nsRect & {x=0 y=15
width=8515 height=6304}) line 694
nsBoxFrame::Reflow(nsBoxFrame * const 0x030be7a0, nsIPresContext * 0x0304c680,
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 593
nsBoxFrame::FlowChildAt(nsIFrame * 0x030be7a0, nsIPresContext * 0x0304c680,
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0,
nsCalculatedBoxInfo & {...}, int & 0, nsString & {"initial"}) line 1153
nsBoxFrame::FlowChildren(nsIPresContext * 0x0304c680, nsHTMLReflowMetrics &
{...}, const nsHTMLReflowState & {...}, unsigned int & 0, nsRect & {x=0 y=0
width=9600 height=6334}) line 694
nsBoxFrame::Reflow(nsBoxFrame * const 0x030bd070, nsIPresContext * 0x0304c680,
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 593
nsBoxFrame::FlowChildAt(nsIFrame * 0x030bd070, nsIPresContext * 0x0304c680,
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0,
nsCalculatedBoxInfo & {...}, int & 1, nsString & {"initial"}) line 1153
nsBoxFrame::FlowChildren(nsIPresContext * 0x0304c680, nsHTMLReflowMetrics &
{...}, const nsHTMLReflowState & {...}, unsigned int & 0, nsRect & {x=0 y=0
width=9600 height=7199}) line 694
nsBoxFrame::Reflow(nsBoxFrame * const 0x030b9870, nsIPresContext * 0x0304c680,
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 593
nsContainerFrame::ReflowChild(nsIFrame * 0x030b9870, nsIPresContext *
0x0304c680, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0,
int 0, unsigned int 0, unsigned int & 0) line 605 + 31 bytes
RootFrame::Reflow(RootFrame * const 0x030b8740, nsIPresContext * 0x0304c680,
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 333
nsContainerFrame::ReflowChild(nsIFrame * 0x030b8740, nsIPresContext *
0x0304c680, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0,
int 0, unsigned int 0, unsigned int & 0) line 605 + 31 bytes
ViewportFrame::Reflow(ViewportFrame * const 0x030b8a70, nsIPresContext *
0x0304c680, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0) line 527
PresShell::InitialReflow(PresShell * const 0x0304da30, int 9600, int 7200) line
1003
nsXULDocument::StartLayout() line 3464
nsXULDocument::ResumeWalk() line 4762
nsXULDocument::EndLoad(nsXULDocument * const 0x0304b7e0) line 1233 + 8 bytes
XULContentSinkImpl::DidBuildModel(XULContentSinkImpl * const 0x0309ac70, int 1)
line 553
CWellFormedDTD::DidBuildModel(CWellFormedDTD * const 0x0309b660, unsigned int 0,
int 1, nsIParser * 0x0309a9f0, nsIContentSink * 0x0309ac70) line 293 + 20 bytes
nsParser::DidBuildModel(unsigned int 0) line 589 + 55 bytes
nsParser::ResumeParse(nsIDTD * 0x00000000, int 1) line 981
nsParser::OnStopRequest(nsParser * const 0x0309a9f4, nsIChannel * 0x0309a260,
nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x00000000)
line 1344 + 19 bytes
nsChannelListener::OnStopRequest(nsChannelListener * const 0x0309a0f0,
nsIChannel * 0x0309a260, nsISupports * 0x00000000, unsigned int 0, const
unsigned short * 0x00000000) line 1590
nsFileChannel::OnStopRequest(nsFileChannel * const 0x0309a264, nsIChannel *
0x0309bf80, nsISupports * 0x00000000, unsigned int 0, const unsigned short *
0x00000000) line 484 + 45 bytes
nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x0309be70) line
279
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x0309b7b0) line 93 + 12 bytes
PL_HandleEvent(PLEvent * 0x0309b7b0) line 537 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x02ded5e0) line 498 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x02490748, unsigned int 49363, unsigned int 0,
long 48158176) line 972 + 9 bytes
USER32! 77e71820()
marked critical, could easily lead to hard-to-reproduce crashes in optimized
builds.
Updated•26 years ago
|
Priority: P3 → P1
Summary: memory corruption in box layout → Dogfood: memory corruption in box layout
Target Milestone: M12
Comment 2•26 years ago
|
||
putting on dogfood radar, targetting M12, P1
Updated•26 years ago
|
Whiteboard: [PDT+] → [PDT+] 12/3/1999
Comment 4•26 years ago
|
||
What build was this? Was it this mornings build? This bug should have been fixed
by the changes I made last night.
Updated•26 years ago
|
Assignee: evaughan → claudius
Comment 6•26 years ago
|
||
Ok so I think this bug is actually fixed. I'll get someone with a newer
comercial build to try to reproduce. But technically my fix did not go in until
the night of the first. So the morning was too early.
Claudious can you confirm this does not happend in the current optimized
comercial build? If it doesn't can you close this out with the others?
-E
Updated•26 years ago
|
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Comment 7•26 years ago
|
||
lets mark it fixed. that is the standard way for things to fall
on the testing and verification radar
Assignee | ||
Updated•26 years ago
|
Whiteboard: [PDT+] 12/3/1999 → [PDT+] 12/3/1999 DEC-9 awaiting feedback
Assignee | ||
Comment 8•26 years ago
|
||
ummm so nobody's got debug builds over here. I've looked at 11/30, 12/01 and 12/09 opt build
and haven't seen any relevent differences in behavior or console output. Unless you can tell me
what to look for in an opt build there's not much I can do here.
Assignee | ||
Comment 9•26 years ago
|
||
adding earlier commentors to Cc: list in hopes of getting a response to my earlier plea.
Assignee | ||
Updated•26 years ago
|
Status: RESOLVED → VERIFIED
Assignee | ||
Comment 10•26 years ago
|
||
VERIFIED fixed with the 1999120908 builds
You need to log in
before you can comment on or make changes to this bug.
Description
•