70335 - Adding <TR>s directly into a <TABLE> causes unpredictable results.

Status: RESOLVED INVALID

(Core :: Layout: Tables, defect)

Description

[Robert Ginda]

I left chatzilla running overnight, and came back to a crash in table
code.  I wasn't here when it happened, so I can't say exactly what was going on,
but chatzilla creates alot of dynamic table content.  This is a new regression,
at least since the 13th, but probably newer than that.

Program received signal SIGSEGV, Segmentation fault.
0x41c89356 in ?? ()
   from
/home/rginda/src/mozilla_RIGHT/mozilla/dist/bin/components/libgklayout.so

(gdb) where
#0  0x41c89356 in BasicTableLayoutStrategy::AssignNonPctColumnWidths (
    this=0x910dad0, aPresContext=0x8acdf68, aMaxWidth=5850, 
    aReflowState=@0xbfffa040, aPixelToTwips=15)
    at BasicTableLayoutStrategy.cpp:900
#1  0x41c87423 in BasicTableLayoutStrategy::Initialize (this=0x910dad0, 
    aPresContext=0x8acdf68, aMaxElementSize=0x0, aMaxWidth=5850, 
    aReflowState=@0xbfffa040) at BasicTableLayoutStrategy.cpp:105
<full trace attached to bug>

(gdb) frame 0
#0  0x41c89356 in BasicTableLayoutStrategy::AssignNonPctColumnWidths (
    this=0x910dad0, aPresContext=0x8acdf68, aMaxWidth=5850, 
    aReflowState=@0xbfffa040, aPixelToTwips=15)
    at BasicTableLayoutStrategy.cpp:900
900           minWidth = PR_MAX(minWidth,
cellFrame->GetPass1MaxElementSize().width);
(gdb) p cellFrame
$1 = (nsTableCellFrame *) 0x92b6668
(gdb) p *cellFrame
$2 = {<nsHTMLContainerFrame> = {<nsContainerFrame> = {<nsSplittableFrame> =
{<nsFrame> = {<nsIFrame> = {<nsISupports> = {
              _vptr. = 0x0}, }, <nsIFrameDebug> = {<nsISupports> = {
              _vptr. = 0x41e1cf00}, }, mRect = {x = 30, y = 0, width = 1395, 
            height = 458}, mContent = 0x0, mStyleContext = 0x0, 
          mParent = 0x92b6618, mNextSibling = 0x92b6898, mState = 4}, 
        mPrevInFlow = 0x0, mNextInFlow = 0x0}, mFrames = {
        mFirstChild = 0x0}}, }, <nsITableCellLayout> = {<nsISupports> = {
      _vptr. = 0x41e24980}, }, mColIndex = 0, mPriorAvailWidth = 1395, 
  mDesiredSize = {width = 1395, height = 248}, mDesiredAscent = 188, 
  mMaximumWidth = 690, mPass1MaxElementSize = {width = 690, height = 255}, 
  mBorderEdges = 0x0}
(gdb) p minWidth
$3 = 1395
(gdb) p cellFrame->GetPass1MaxElementSize()
Cannot access memory at address 0x0.

Comment 1

[Robert Ginda]

Attachment: full stack trace from crash

Comment 2

[Robert Ginda]

same crash last night, with yesterday's build.

Comment 3

[Robert Ginda]

I think I found the cause of this crash.  I had been appending <TR>s directly
into a <TABLE> (via the DOM), instead of placing the <TR>s in a <TBODY>, and the
<TBODY> in the <TABLE>.  This cause lots of other *intermittent* wierdness as
well; links in the table did not work, new table cells would not always paint,
and new table cells could not be selected.

I've updated chatzilla to use <TBODY>s and it all seems to be fixed, but I don't
think we should act so funny when someone puts bad children in the table.  Maybe
an exception should be thrown or something?

Resummarizing.

Comment 4

[Samuel Sieb]

The crash occurs at:
http://lxr.mozilla.org/mozilla/source/layout/html/table/src/BasicTableLayoutStrategy.cpp#900
The big question though is why cellFrame contains an invalid pointer.
(It's not null)

Comment 5

[Dan Rosen]

Could it have something to do with this?:

  http://www.w3.org/TR/REC-CSS2/tables.html#anonymous-boxes

CSS has some fu that it needs done when <tr> appears as a child of <table>.
Could be that the anonymous table box code in nsCSSFrameConstructor is biting us
hard...

Comment 6

[Amarendra Hanumanula]

QA contact update

Comment 7

[Christopher Hoess (gone)]

adding keyword.

Comment 8

[karnaze (gone)]

Attachment: test that adds TRs directly into TABLE and doesn't crash

Comment 9

[karnaze (gone)]

rginda, please attach a test case that crashes. I attached one that doesn't 
crash.

Comment 10

[karnaze (gone)]

Marking invalid since there is no url or test case exhibiting the problem.