217201 - mozilla >= 1.4 crashes when browsing a specific URL [@ nsBlockFrame::GetTopBlockChild ]

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[Johann Aydinbas]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030807
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030807

Whenever I browse this URL my mozilla 1.4 closes. This is reproducable and works
both with linux and windows versions of mozilla. Also mozilla and firebird seem
to be vulnerable to this.
The order of the two words doesn't matter, words=framebuffer%20tty also works.
Sometimes the browser didn't close but my mozilla closed every time when
browsing this URL.
It seems like that mozilla or mozilla based browser with a version greater than
or equal to 1.4 is vulnerable.
Severel mozilla 1.0 and 1.3 opened the URL flawless.

Here is the information about the systems where the bug is reproducable:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030805 Mozilla
Firebird/0.6.1
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030728
Firebird/0.6.1
Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.4) Gecko/20030624 Mozilla 1.4

Not vulnerable:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623
Debian/1.0.0-0.woody.1



Reproducible: Always

Steps to Reproduce:
1.Open the URL mentioned in the URL field
2. -
3. -

Actual Results:  
Mozilla closed without any error message, no Seg Fault. Nothing.

Expected Results:  
Opened the URL

No error messages so it seems not to be a Segmentation Fault.

Comment 1

[Bill Mason]

WFM 20030824 PC/WinXP

Comment 2

[Mihail Daskalov]

crashes with GPF on Windows 2000 Server, 
build 2003082404
talkback ID: will specify after it's successfully sent.

Comment 3

[Mitch]

Provide a stack trace

http://www.mozilla.org/unix/debugging-faq.html

Comment 4

[Hermann Schwab]

TB23036378E Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5b) Gecko/20030822

Comment 5

[Hermann Schwab]

TB23036771W, TB23036522K, TB23036378E on BuildID 2003082204, Win98SE

did some searches with the search box on http://tldp.org for "xx xx",
"framebuffer xx", "xx tty", partly with and without doublequoutes, no
difference, no crash.
"Framebuffer tty" crashes with and without doublequotes.

view-source:http://tldp.org/cgi-bin/ldpsrch.cgi?words=tty%20framebuffer enabled
me to download the search result, the local copy could be started without a crash.

Comment 6

[Johann Aydinbas]

strace for mozilla (after browsing the URL)

--------------------------------------------------------------------------------------------------------------
[WIFEXITED(s) && WEXITSTATUS(s) == 11], 0, NULL) = 3652
rt_sigprocmask(SIG_BLOCK, [CHLD TTOU], [CHLD], 8) = 0
rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0
rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
wait4(-1, 0xbffff09c, WNOHANG, NULL)    = -1 ECHILD (No child processes)
sigreturn()                             = ? (mask now [])
rt_sigaction(SIGINT, {SIG_DFL}, {0x8060ef0, [], SA_RESTORER, 0x80b1188}, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
stat64("core", 0xbffff390)              = -1 ENOENT (No such file or directory)
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_BLOCK, [CHLD TTOU], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
read(255, "\nexit $exitcode\n", 8176)   = 16
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_BLOCK, [CHLD TTOU], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
exit_group(11)                          = ?
-----------------------------------------------------------------------------------------------------

Comment 7

[Mitch]

strace is useless in ths instance. Please provide a stacktrace from gdb or if
anyone knows how to decode the talkback's from windoze into a stacktrace then 
please attach or search bugzilla for other matches.

Comment 8

[Mats Palmgren (inactive)]

Attachment: GDB stack trace

Comment 9

[Mats Palmgren (inactive)]

-> Layout

Comment 10

[Mats Palmgren (inactive)]

-> Layout

Comment 11

[Mats Palmgren (inactive)]

Stack looks a bit like bug 165393

Comment 12

[Hermann Schwab]

Bug 165393 crash when flash plug-in enabled [nsBlockFrame::GetTopBlockChild]

depends on an installed Flash plugin, I don´t have flash installed,
the only plugin I´ve installed is Java 1.4.2

tried to open the URL in DOM Inspector:

TB23036952H Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5b) Gecko/20030822

Comment 13

[Mihail Daskalov]

talkback ID: TB23035519E

Is it possible to get a stacktrace from Windows?
I have MSVC v.6.0 installed, but no sources for Mozilla.
When a crash occurs I could say cancel and go to the MSVC debugger, in the
Disassembly window - but it's not much usefull.

It would be great if someone points me to a document about this, so that I could
help more in future bugs...

Comment 14

[Mats Palmgren (inactive)]

> depends on an installed Flash plugin

No, it does not.  Read the bug.  I don't have Flash installed either.

Comment 15

[WD]

Attachment: VS7 stack trace from crash

Comment 16

[WD]

Is this related to bug 204915 , bug 207365 , or bug 216961 ?
(which are caused by the fix for bug 201767 )

Comment 17

[Chris Casciano]

-> All/All (repro'd on 2003082403/OS X w/ a stack similar to the atached vs7 stack)

Comment 18

[Mats Palmgren (inactive)]

I backed out bug 201767 too, but I still see the crash.  It was slightly
harder to reproduce - I had to submit the upper form a few times.

WD, could you attach your backout-patch, maybe I did something wrong?

Comment 19

[WD]

I am pretty certain that the bugs I listed were caused by the patch for bug 201767
I filed bug 204915 , but it's been somewhat tricky to test as the
reproducibility is about 1/30 tries.

I am not sure about this one.  (Though the stack traces are similar).   Maybe a
good test would be to try a build from before and after the fix for bug 201767 ?
 (if they're available anywhere)

The files have changed a bit since the patch, so I couldn't back it out totally.
 I attempted a partial back-out, but Mozilla still crashed.

Comment 20

[Hermann Schwab]

testing on Win98 with a slow Celeron 333: 
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5b) Gecko/20030824 
TB23046307X, TB23046302Y 

1. could view and download URL with Mozilla 1.3.1
2. in the office could download source with 1.4 using
view-source:http://tldp.org/cgi-bin/ldpsrch.cgi?words=tty%20framebuffer

3. can view downloaded file locally with 1.4, Win98, Win98SE
That is like seen in bug 208791 comment 6 (dupe of bug 207365)
Lots of data in this bug.

4. from a look at DocWatson log for Bug 216343 aocusa.com crashes browser,
I see the same crash in editor.DLL over there.
Maybe someone better in reading the attached Win2k stacks can compare.

5. When I loaded the saved file locally in a tab, and opened the URL in another
one, the website got displayed, I assume from memory cache?,  before crashing.
When I restarted the browser, and only loaded the URL in this bug window, the
website didn´t replace the bug window, only DocWatson and Talkback came up. 

Comment 21

[Andrew Schultz]

this regressed between linux trunk 2003042105 and 2003042205, which does match
201767

I was unable to reproduce this loading the page locally or even from a local server.

Comment 22

[Hermann Schwab]

Bug 208791 regressed between BuildID 2003042112 (working) and BuildId 2003042204
(crashing), tested on windows98SE, as seen in Bug 208791 comment 7

Comment 23

[Mats Palmgren (inactive)]

Attachment: Assertions immediatly before crash (Linux)

Comment 24

[Mats Palmgren (inactive)]

I agree with WD, everything points to bug 201767 as the culprit.
I checked out and built -D"2003-04-21 18:35 PDT" and it crashed.
I then backed out 201767 and it did not crash.

Comment 25

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

I can't reproduce this at this URL. Hmm.

Comment 26

[Andrew Schultz]

Attachment: original URL

This is the original page (as of 8-26).  It's changed since then.  I got this
to crash (CVS trunk), loading it from a remote server a few times.

Comment 27

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

YES! you rock my world

Comment 28

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

Attachment: valgrind output

This is valgrind output from running Andrew's testcase. I had to hack a little
Web server to feed the file to Mozilla very slowly to trigger the crash.

The bad stuff starts here:

###!!! ASSERTION: We should not get in here if aContainer is in some _other_
document!: 'aContainer->GetDocument() == mDocument', file nsContentList.cpp,
line 914
Break: at file nsContentList.cpp, line 914
^G==4635==
==4635== Invalid read of size 4
==4635==    at 0x45335354: nsTypedSelection::EndBatchChanges()
(nsSelection.cpp:7715)
==4635==    by 0x4D83D229: nsEditor::DoTransaction(nsITransaction*)
(nsEditor.cpp:540)
==4635==    by 0x4D83F725: nsEditor::DeleteNode(nsIDOMNode*) 

The accesses is to memory that has already been freed. No doubt memory
corruption ensues.

Comment 29

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

Attachment: stacktrace of "We should not get in here if aContainer is in some _other_ document!" assertion

(different run from the valgrind run, obviously)

Comment 30

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

Attachment: stacktrace showing reentrancy

This stacktrace seems to show the core problem.

The first reflow of the textfield sets the initial value. This requires a DOM
update, which flushes the content sink. The sink appends new content to the
document. In this case, this triggers IB processing which wipes the containing
block and tries to reframe it, which destroys the textfield which we're
currently reflowing (and other frames too). The removal of the textfield
anonymous content from the document is the immediate cause of the asserts.

I'm not sure why this only started showing up when bug 201767 was fixed. It
seems like it must have always been possible.

Comment 31

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

What is really supposed to happen here, anyway?

I suspect the "right thing" is to not be updating the text field during reflow.

Comment 32

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

That sounds a lot like the chain of events in bug 210269.  I think "don't change
content during reflow" is a good rule.  (That's why I was advocating what I did
in bug 136927.)

Comment 33

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

I'll try moving the InitEditor() out of Reflow() to AppendFrames/InsertFrames
(when frames have been created for the anonymous children). The comments warn
about a forms-related regresion though.

Comment 34

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

Attachment: fix

Here we go. I've moved the InitEditor out into a new
nsIAnonymousContentCreator::PostCreateFrames method. It fixes the crash and
forms seem to work OK.

However, this is the kind of patch that could have unforseen consequences
(forms, events, oh my!). Should probably bake on trunk after branch before
landing in 1.5.

Comment 35

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

Comment on attachment 131117 [details] [diff] [review]
fix

>Index: layout/html/base/src/nsIAnonymousContentCreator.h
>      // If the creator doesn't want to create special fframe ro frame hierarchy
>      // then it should null out the style content arg and return NS_ERROR_FAILURE

Maybe clean up this comment to get rid of "null out the style context arg"
(eh?), and fix the spelling on the line before?

>      NS_IMETHOD CreateFrameFor(nsIPresContext*   aPresContext,
>                                nsIContent *      aContent,
>                                nsIFrame**        aFrame)=0;
>+
>+     // This gets called after the frames for the anonymous content have been
>+     // created and added to the frame tree. By default it does nothing.

"By default it does nothing." seems redudant.  It's pure virtual.  Or were you
trying to say something else?

Also, "anonymous content has".

r+sr

Comment 36

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

> "By default it does nothing." seems redudant.  It's pure virtual.

No, it is not :-).

> Also, "anonymous content has".

No, "has" agrees with "frames".

> Maybe clean up this comment to get rid of "null out the style context arg"
> (eh?), and fix the spelling on the line before?

will do.

Comment 37

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

Oh, right.

Comment 38

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

Attachment: Actual patch for checkin

Actual patch to check in

Comment 39

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

Fix checked in.

Comment 40

[Mike Kaply [:mkaply]]

This caused a major Bidi regression.

See:

http://bugzilla.mozilla.org/show_bug.cgi?id=228156

Comment 41

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED using build 2004-11-12-04 on Windows XP Seamonkey trunk.