121368 - Crash when loading a page containing search results M098 [@ nsTypedSelection::EndBatchChanges][@ nsContainerFrame::FinishReflowChild]

Status: VERIFIED FIXED

(Core :: Layout, defect, P2)

Description

[Alexandre Vitrac]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.7) Gecko/20011226
BuildID:    2001122614

On the Compaq support site, there is a search field where you can enter
search terms and validate with the "Go" button.

If I enter any search term and press "Go", the page starts to load, but
nothing is displayed and then the browser coredumps.


Reproducible: Always
Steps to Reproduce:
1. Load http://www.compaq.com/support/
2. Enter search term in the search box on the left
3. Press Go.

Actual Results:  The browser crashes and dumps a core.

Expected Results:  The browser should have loaded and displayed the search results.


This is a local build of the Mozilla 0.9.7 source code, on a
Solaris 7 system.

It was compiled with gcc 2.95.3, using the following options in configure :
--disable-xprint --disable-tests --disable-debug --enable-crypto 
--enable-ultrasparc --enable-optimize="-O3" --without-jpeg 
--without-zlib --without-png

Comment 1

[Alexandre Vitrac]

Attachment: gdb backtrace with the generated core file

This contains a backtrace of the core and the full list of loaded libraries.

Comment 2

[Erik Hensema]

Also crashes on Linux 2002012121

Comment 3

[Ludovic Hirlimann]

This is also tru on w2k build ID 2002011703. TalkbackID= TB2003770G.
Reporter you can change OS => ALL and platform to ALL.

Comment 4

[Matthias Versen [:Matti]]

Attachment: win2k stack trace

Comment 5

[Matthias Versen [:Matti]]

my win2k stack is a little bit different.
The SunOS stack is -> Layout, my win2k stack is -> selection (?)

Marc Attinasi/[e-mail] : Please help :-)

Comment 6

[Chris Petersen]

Changing QA Contact

Comment 7

[Kevin McCluskey (gone)]

Crashes using 2002012203 build on WINXP

Comment 8

[Andrew Hagen]

*** Bug 121511 has been marked as a duplicate of this bug. ***

Comment 9

[Andrew Hagen]

Talkback ID's on Windows 98, 0.9.7, Build ID: 2002012304: TB2038294G,
TB2038385X, and TB2038487G.

Comment 10

[greer]

Attachment: Stack from Win2k crashes

When I use the repro steps listed (on Win2K, Trunk build 2002012309) I get a
different stack. (attached).

Note: Stacks for incidents in comment #9 match the stack in comment #4.

Comment 11

[greer]

Just tried the steps using build 2002012506 to reproduce my earlier crash. But 
it didn't crash. Could this be due to jst's checkin in nsContainerFrame.cpp on 
1/24 ?

Comment 12

[Andrew Hagen]

Worksforme now, Windows 98, 0.9.7, Build ID: 2002012503. Resolving as worksforme
on that basis and the previous comment, which also reported it working.

Comment 13

[R.K.Aa.]

*** Bug 122562 has been marked as a duplicate of this bug. ***

Comment 14

[Moied]

verified WFM with Build ID 20020131

Comment 15

[Matthias Versen [:Matti]]

*** Bug 123255 has been marked as a duplicate of this bug. ***

Comment 16

[greer]

This one is back as a topcrasher in M098. I can reproduce the crash every time 
with reporter's steps. 
Go to www.compaq.com, enter text in the search form and click 'Go' -> crash. 

This one needs to get fixed. Nominating.

Comment 17

[Kevin McCluskey (gone)]

Marking nsbeta1+

Comment 18

[Matthias Versen [:Matti]]

*** Bug 125699 has been marked as a duplicate of this bug. ***

Comment 19

[Moied]

Just tried repro steps listed above with build ID 20020214 on win2k and Linux,
can’t able to reproduce the crash.

Comment 20

[R.K.Aa.]

*** Bug 125786 has been marked as a duplicate of this bug. ***

Comment 21

[Matthias Versen [:Matti]]

*** Bug 126597 has been marked as a duplicate of this bug. ***

Comment 22

[Jason Brisch]

Attachment: Stripped-down HTML code that causes crash

This is the HTML code generated by Compaq's site, with the minimum code
required to crash Mozilla.  This error is caused by a NOBR tag not being
closed, with some Javascript code nested in the "open" NOBR tag.  I experienced
this crash on build 20020204 under Win2k and build 20011226 under Linux.

Comment 23

[Alexandru Savulov]

taking

Comment 24

[Alexandru Savulov]

Attachment: proposed patch V1.0 - prevents nsCSSFrameConstructor::ReframeContainingBlock execute during reflow

this is the first patch that comes in my mind that fixes the crash. maybe i can
refine it a little bit and make it a little bit more tolerant

Comment 25

[Alexandru Savulov]

i will create another patch to also repair the crash 

@nsTypedSelection::EndBatchChanges

(proper refcounting for a member pointer solves that)

Comment 26

[Alexandru Savulov]

2 things:

1. i will open another bug for the nsTypedSelection problem

and

2. I had a talk with Marc Attinasi and decided not to try make this patch more
tolerant since the method ReframeConatainingBlock is supposed to be remioved in
the future by a better implementation

Comment 27

[karnaze (gone)]

This may solve the crash, but is it a temporary fix? How is the reframe going to 
occur?

Comment 28

[Marc Attinasi]

Comment on attachment 72175 [details] [diff] [review]
proposed patch V1.0 - prevents nsCSSFrameConstructor::ReframeContainingBlock execute during reflow

sr=attinasi

Comment 29

[Alexandru Savulov]

r= comes from Chris Karnaze

Comment 30

[Asa Dotzler [:asa]]

Comment on attachment 72175 [details] [diff] [review]
proposed patch V1.0 - prevents nsCSSFrameConstructor::ReframeContainingBlock execute during reflow

a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Comment 31

[Alexandru Savulov]

fixed on trunk

Comment 32

[R.K.Aa.]

*** Bug 129989 has been marked as a duplicate of this bug. ***

Comment 33

[Matthias Versen [:Matti]]

*** Bug 130548 has been marked as a duplicate of this bug. ***

Comment 34

[Jeroen Ruigrok van der Werven]

Yes, 0.9.9 on FreeBSD solves the problems I had.
Thanks.

Comment 35

[greer]

Not seeing this one in M099 or Trunk talkback data. VERIFIED.

Comment 36

[Jim Gettys]

Fixed for me on Linux in 0.9.9...

Comment 37

[Marc Attinasi]

I think the nsTypedSelection bug is filed at
http://bugzilla.mozilla.org/show_bug.cgi?id=117695

Comment 38

[Chris Waterson]

kin: attachment 66095 [details] indicates that this is a crash caused by editor creating
content during reflow. So, if we ever _do_ fix the text control so that they can
create frames during creation, we can back out this fix. (Should we file a bug
on that?)