204915 - Crash in [@ nsBlockFrame::DoReflowInlineFrames] when rendering pop-up window on pinnacle webboard

Status: RESOLVED DUPLICATE of bug 210269

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

Description

[WD]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030506
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030506

On the Pinnacle Webboard, there's an icon to click to view a user's profile. 
This info comes up in a pop-up window.   The pop up will appear, but frequently
mozilla will crash immediately after that.

Reproducible: Sometimes

Steps to Reproduce:
1.Go to the URL for this bug
2.Click on the link in any of the posts to go to a user's profile.  (The image
with a person's profile and a question mark)
3.

Actual Results:  
Crash

Expected Results:  
No crash

TB19903233Q

Per IRC conversation:   Stack ends in nsBlockFrame::DoReflowInlineFrames
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 3754]

Comment 1

[WD]

OS -> ALL, per IRC

Comment 2

[kirun]

Talkback ID for Linux 2003051308 :

TB20062014M

Comment 3

[WD]

The fix for Bug 201767 seems to cause this...

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

There's another bug on the crashes caused by that fix that has significantly
more discussion, I think.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Not that I'm CC'ed on

Comment 6

[Kai Engert (:KaiE:)]

The crash is in editor.

I checked out the file by date, talkback says we are crashing on the line marked
with =>

    if (!selection) { return NS_ERROR_NULL_POINTER; }
=>  nsCOMPtr<nsISelectionPrivate>selPrivate(do_QueryInterface(selection));

    selPrivate->StartBatchChanges();

I guess we can't actually crash on that line, can we?
I suspect we can only crash on the following line.

WD: Could you try to edit file mozilla/editor/libeditor/base/nsEditor.cpp
and add the following new line marked with * ?

    if (!selection) { return NS_ERROR_NULL_POINTER; }
    nsCOMPtr<nsISelectionPrivate>selPrivate(do_QueryInterface(selection));
*   if (!selPrivate) { return NS_ERROR_NULL_POINTER; }
    selPrivate->StartBatchChanges();

Does that fix your crash?


The first lines from the stack trace are:

0x00000000
nsEditor::DoTransaction()
[/builds/client/linux22/seamonkey/mozilla/editor/libeditor/base/nsEditor.cpp,
line 536]
nsEditor::DeleteNode()
[/builds/client/linux22/seamonkey/mozilla/editor/libeditor/base/nsEditor.cpp,
line 1360]
nsTextEditRules::WillInsert()
[/builds/client/linux22/seamonkey/mozilla/editor/libeditor/text/nsTextEditRules.cpp,
line 361]
nsTextEditRules::WillInsertText()
[/builds/client/linux22/seamonkey/mozilla/editor/libeditor/text/nsTextEditRules.cpp,
line 526]
nsTextEditRules::WillDoAction()
[/builds/client/linux22/seamonkey/mozilla/editor/libeditor/text/nsTextEditRules.cpp,
line 287]
nsPlaintextEditor::InsertText()
[/builds/client/linux22/seamonkey/mozilla/editor/libeditor/text/nsPlaintextEditor.cpp,
line 998]
nsTextControlFrame::SetValue()
[/builds/client/linux22/seamonkey/mozilla/layout/html/forms/src/nsTextControlFrame.cpp,
line 3029]
nsTextControlFrame::InitEditor()
[/builds/client/linux22/seamonkey/mozilla/layout/html/forms/src/nsTextControlFrame.cpp,
line 1584]
nsTextControlFrame::Reflow()
[/builds/client/linux22/seamonkey/mozilla/layout/html/forms/src/nsTextControlFrame.cpp,
line 1935]
nsLineLayout::ReflowFrame()
[/builds/client/linux22/seamonkey/mozilla/layout/html/base/src/nsLineLayout.cpp,
line 1034]
nsInlineFrame::ReflowInlineFrame()
[/builds/client/linux22/seamonkey/mozilla/layout/html/base/src/nsInlineFrame.cpp,
line 735]

Comment 7

[Kai Engert (:KaiE:)]

Ok, possibly the previous stack trace was something else, or an incorrectly
reported stack.

WD gave me TB ID 21041073 and some other IDs, which all crash here:

Access violation
nsBlockFrame::DoReflowInlineFrames
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 3609]
nsBlockFrame::DoReflowInlineFramesAuto
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 3497]
nsBlockFrame::ReflowInlineFrames
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 3442]
nsBlockFrame::ReflowLine
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 2546]
nsBlockFrame::ReflowDirtyLines
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 2192]
nsBlockFrame::Reflow
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 862]
nsBlockReflowContext::ReflowBlock
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockReflowContext.cpp, line
544]
...

Comment 8

[WD]

Here's my console output up to the point where I crash:

Document http://webboard.pinnaclesys.com/read_messages.asp?WebboardID=1&ForumID=
704&SectionID=143&ThreadID=144921&ThreadStart=0&Pos=0&cntThread=50&lng=1 loaded
successfully
WEBSHELL+ = 4
WEBSHELL+ = 5
###!!! ASSERTION: We should not get in here if aContainer is in some _other_ doc
ument!: 'doc == mDocument', file f:/MOZILL~1/mozilla/content/base/src/nsContentL
ist.cpp, line 1000
###!!! ASSERTION: We should not get in here if aContainer is in some _other_ doc
ument!: 'doc == mDocument', file f:/MOZILL~1/mozilla/content/base/src/nsContentL
ist.cpp, line 1000

Comment 9

[WD]

Attachment: Stack Trace from Visual Studio

Here is a stack trace from a Win32 Debug build.  The line that crashes is this
one:
http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsBlockFrame.cpp#3585

Comment 10

[WD]

Where the access violation occurs, here are some values:
aLine.mCurrent._mNext = 0x03c58003
aLine.mCurrent._mPrev = 0xcdcdcdcd

The inline function being called:
http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsLineBox.h#1228
is failing because the mPrev pointer seems to be uninitialized

Comment 11

[Chris Casciano]

-> All/All

I can repro this crash inside a handful of tries on OS X (Camino 082302 trunk &
moz 082403 trunk)

Comment 12

[WD]

Not sure about the exact dependency here, but the common theme is that the fix
for Bug 201767 is the culprit.

Luckily bug 217201 is seemingly much easier to reproduce than this one.

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I think we need to fix this for 1.5.  There are a bunch of bugs that are
regressions from bug 201767.  If necessary, we should probably back out the fix
(and perhaps replace it with an overflow list check in the place necessary to
fix that bug).

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'm very sure this is a duplicate of 217201.

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

OK, so my fix for bug 217201 changes this ... now it gives the SetAttr call
stack of bug 210269!

Comment 16

[beanladen]

I can't reproduce the problem with 1.5b 2003082822 Linux i686 gcc-2.95.3 compiled.

Comment 17

[beanladen]

And also does not crash for bug 217201 nor bug 210269 !

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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