Closed Bug 118421 Opened 23 years ago Closed 8 years ago

Uninitialized memory read in nsLineLayout::VerticalAlignLine

Categories

(Core :: Layout: Block and Inline, defect, P1)

x86
Windows 2000
defect

Tracking

()

RESOLVED WORKSFORME
Future

People

(Reporter: stephend, Unassigned)

Details

(Keywords: helpwanted)

Build ID: Latest Win32 trunk bits (pulled from CVS)

Steps to Reproduce:

1.  Launch mozilla.exe -mail
2.  Expand and then collapse a folder in the Mail Folder Pane.

UMR: Uninitialized memory read in nsLineLayout::VerticalAlignLine(nsLineBox
*,nsSize&,int&) {2 occurrences}
        Reading 4 bytes from 0x0013e448 (4 bytes at 0x0013e448 uninitialized)
        Address 0x0013e448 points into a thread's stack 
        Address 0x0013e448 is 308 bytes past the start of local variable
'lineLayout' in
nsBlockFrame::DoReflowInlineFramesAuto(nsBlockReflowState&,nsLineList_iterator,int
*,BYTE *,int,int)
        Thread ID: 0x4d4
        Error location
        nsLineLayout::VerticalAlignLine(nsLineBox *,nsSize&,int&)
[nsLineLayout.cpp:1949]
            if (mComputeMaxElementSize) {
        
              nscoord mw = pfd->mMaxElementSize.width +
     =>         pfd->mMargin.left + pfd->mMargin.right;
              if (psd->mNoWrap) {
                maxElementWidth += mw;
              }
       
nsBlockFrame::PlaceLine(nsBlockReflowState&,nsLineLayout&,nsLineList_iterator,int
*,int) [nsBlockFrame.cpp:4064]
          }
          nsSize maxElementSize;
          nscoord lineAscent;
     =>   aLineLayout.VerticalAlignLine(aLine, maxElementSize, lineAscent);
          // Our ascent is the ascent of our first line
          if (aLine == mLines.front()) {
            mAscent = lineAscent;
       
nsBlockFrame::DoReflowInlineFrames(nsBlockReflowState&,nsLineLayout&,nsLineList_iterator,int
*,BYTE *,int,int) [nsBlockFrame.cpp:3709]
            // If we are propagating out a break-before status then there is
            // no point in placing the line.
            if (!NS_INLINE_IS_BREAK_BEFORE(aState.mReflowStatus)) {
     =>       rv = PlaceLine(aState, aLineLayout, aLine, aKeepReflowGoing,
aUpdateMaximumWidth);
            }
          }
          *aLineReflowStatus = lineReflowStatus;
       
nsBlockFrame::DoReflowInlineFramesAuto(nsBlockReflowState&,nsLineList_iterator,int
*,BYTE *,int,int) [nsBlockFrame.cpp:3561]
          lineLayout.Init(&aState, aState.mMinLineHeight, aState.mLineNumber);
          nsresult rv = DoReflowInlineFrames(aState, lineLayout, aLine,
                                             aKeepReflowGoing, aLineReflowStatus,
     =>                                      aUpdateMaximumWidth, aDamageDirtyArea);
          lineLayout.EndLineReflow();
          return rv;
        }
       
nsBlockFrame::ReflowInlineFrames(nsBlockReflowState&,nsLineList_iterator,int
*,int,int) [nsBlockFrame.cpp:3505]
            else {
              rv = DoReflowInlineFramesAuto(aState, aLine, aKeepReflowGoing,
                                            &lineReflowStatus,
     =>                                     aUpdateMaximumWidth, aDamageDirtyArea);
            }
            if (NS_FAILED(rv)) {
              break;
        nsBlockFrame::ReflowLine(nsBlockReflowState&,nsLineList_iterator,int
*,int) [nsBlockFrame.cpp:2549]
              // end up resetting the line's right edge and have it think the
              // width is unconstrained...
              aState.SetFlag(BRS_UNCONSTRAINEDWIDTH, PR_TRUE);
     =>       ReflowInlineFrames(aState, aLine, aKeepReflowGoing,
aDamageDirtyArea, PR_TRUE);
              aState.mY = oldY;
              aState.mPrevBottomMargin = oldPrevBottomMargin;
              aState.SetFlag(BRS_UNCONSTRAINEDWIDTH, oldUnconstrainedWidth);
        nsBlockFrame::ReflowDirtyLines(nsBlockReflowState&) [nsBlockFrame.cpp:2178]
              if (incrementalReflow) {
                forceInvalidate = !IsIncrementalDamageConstrained(aState);
              }
     =>       rv = ReflowLine(aState, line, &keepGoing, forceInvalidate);
              if (NS_FAILED(rv)) {
                return rv;
              }
        nsBlockFrame::Reflow(nsIPresContext
*,nsHTMLReflowMetrics&,nsHTMLReflowState const&,UINT&) [nsBlockFrame.cpp:844]
          if (NS_FAILED(rv)) return rv;
        
          // Now reflow...
     =>   rv = ReflowDirtyLines(state);
          NS_ASSERTION(NS_SUCCEEDED(rv), "reflow dirty lines failed");
          if (NS_FAILED(rv)) return rv;
        
    nsBoxToBlockAdaptor::Reflow(nsBoxLayoutState&,nsIPresContext
*,nsHTMLReflowMetrics&,nsHTMLReflowState const&,UINT&,int,int,int,int,int)
[nsBoxToBlockAdaptor.cpp:832]
               // place the child and reflow
            mFrame->WillReflow(aPresContext);
        
     =>     mFrame->Reflow(aPresContext, aDesiredSize, reflowState, aStatus);
        
            NS_ASSERTION(NS_FRAME_IS_COMPLETE(aStatus), "bad status");
        
    nsBoxToBlockAdaptor::RefreshSizeCache(nsBoxLayoutState&)
[nsBoxToBlockAdaptor.cpp:347]
                        rect.x,
                        rect.y,
                        rect.width,
     =>                 rect.height);
        
            nsRect newRect;
            mFrame->GetRect(newRect);
Target Milestone: --- → mozilla1.0
Marking nsbeta1+
Keywords: nsbeta1+
Not known if this is actually causing a problem (i.e. crash). Marking as P2.

adding jpatel. do we see any crashers out in the wild associated with this bug.
Keywords: helpwanted
Priority: -- → P2
I don't recall any topcrashers involving expanding and collapsing folders in
mail...but it would be helpful if someone can reproduce this with a Talkback
enabled build and submit their incidents so we can see what the stack signature
and trace look like.

stephend:  Are you able to reproduce this easily?  If you can, please do so with
a Talkback build.  Thanks!
Whoops...forgot that this wasn't a known crash yet...but *IF* we can crash, it
would be nice to have a Talkback incident to go with it!
Alex can you look at this one?
Assignee: attinasi → alexsavulov
Marking nsbeta1- since Engineers are overloaded with higher priority bugs and
there aren't any known crashers related to this. If a crasher can be attributed
to this please clear the -.
Keywords: nsbeta1+nsbeta1-
Priority: P2 → P1
Target Milestone: mozilla1.0 → Future
->Layout: Block&Inline
Assignee: alexsavulov → block-and-inline
Component: Layout → Layout: Block & Inline
QA Contact: petersen → ian
Assignee: layout.block-and-inline → nobody
QA Contact: ian → layout.block-and-inline
This bug is probably from a time when nsMargin didn't initialize its
members in the ctor.  Pretty sure this should be fixed now.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.