265404 - some more crashes detected by mangler.cgi

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[georgi - hopefully not receiving bugspam]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040914 Firefox/0.10
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040914 Firefox/0.10

some more crashes generated by mangle.cgi.
tested on firefox 0.10. some of them don't work on mozilla 1.7.3
will attached them.

no debugged stack.

ma3.html - may be X bug, the stack seems fucked:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1085497312 (LWP 9982)]
0x40436824 in gdk_window_impl_x11_get_type () from /usr/lib/libgdk-x11-2.0.so.0
(gdb) info stack
#0  0x40436824 in gdk_window_impl_x11_get_type ()
   from /usr/lib/libgdk-x11-2.0.so.0
Cannot access memory at address 0xbf7ffff8
(gdb) x/i $eip
0x40436824 <gdk_window_impl_x11_get_type+4>:
    call   0x403f9023 <gdk_set_program_class+83>
(gdb) 


ma4.html - eip == 0
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1085497312 (LWP 10038)]
0x00000000 in ?? ()
(gdb) info stack
#0  0x00000000 in ?? ()
(gdb)

ma5.html - similar to ma3. the stack isn't very consistent. on first look like
infite recursion, not sure.


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1085497312 (LWP 10043)]
0x40436820 in gdk_window_impl_x11_get_type () from /usr/lib/libgdk-x11-2.0.so.0
(gdb) info stack
#0  0x40436820 in gdk_window_impl_x11_get_type ()
   from /usr/lib/libgdk-x11-2.0.so.0
#1  0x4042b6db in _gdk_window_move_resize_child ()
   from /usr/lib/libgdk-x11-2.0.so.0
(gdb) x/i $eip
0x40436820 <gdk_window_impl_x11_get_type>:      push   %ebx

ma6.html - like ma5.html


Reproducible: Always
Steps to Reproduce:

Comment 1

[georgi - hopefully not receiving bugspam]

Attachment: ma3.html

ma3.html

Comment 2

[georgi - hopefully not receiving bugspam]

Attachment: ma4.html

ma4.html

Comment 3

[georgi - hopefully not receiving bugspam]

Attachment: ma5.html

ma5.html

Comment 4

[georgi - hopefully not receiving bugspam]

Attachment: ma6.html

ma6.html

Comment 5

[georgi - hopefully not receiving bugspam]

Attachment: ma8.html (use ma8main.html)

Comment 6

[georgi - hopefully not receiving bugspam]

Attachment: ma8main.html

Comment 7

[georgi - hopefully not receiving bugspam]

ma8.html works on both mozilla 1.7.3 and firefox 0.10.

the crash is in different locations, seems to be dependent on previous history.

several times crashed in free() after delete() which indicates there may be heap
overflow.

Comment 8

[Daniel Veditz [:dveditz]]

These need to be investigated and reduced to minimal cases, and probably split
into more than one bug. If you're not going to do it, would it be OK to remove
the confidential flag and see if we can get more help in on it?

Comment 9

[georgi - hopefully not receiving bugspam]

of course i don't mind removing the security flag for this bug and/or splitting.

i believed it added some minimal protection.

i tried some of the testcases under valgrind, but then they didn't seem to crash.
probably "efence" may help for the heap ones.
will try to reduce them, but not sure.

Comment 10

[Johnny Stenback (:jst)]

Comment on attachment 162824 [details]
ma3.html

WFM now (most likely fixed by bug 264956).

Comment 11

[Johnny Stenback (:jst)]

Comment on attachment 162827 [details]
ma5.html

WFM now (most likely fixed by bug 264956).

Comment 12

[Johnny Stenback (:jst)]

Comment on attachment 162828 [details]
ma6.html

WFM now (most likely fixed by bug 264956).

Comment 13

[Johnny Stenback (:jst)]

ma4.html crashes (sometimes not on the first load) with the following on the
stack (aParentFrame looks dead):

dddddddd	
nsCSSFrameConstructor::FindFrameWithContent(aPresContext=0x034f2798,
aFrameManager=0x036dec08, aParentFrame=0x03503c90, aParentContent=0x034b6928,
aContent=0x03771008, aHint=0x00000000)	C++
nsCSSFrameConstructor::FindPrimaryFrameFor(aPresContext=0x034f2798,
aFrameManager=0x036dec08, aContent=0x03771008, aFrame=0x0012f234,
aHint=0x00000000)	C++
nsFrameManager::GetPrimaryFrameFor(aContent=0x03771008)	C++
PresShell::GetPrimaryFrameFor(aContent=0x03771008, aResult=0x0012f284)	C++
nsCSSFrameConstructor::GetFrameFor(aPresShell=0x036debf0,
aPresContext=0x034f2798, aContent=0x03771008)	C++
nsCSSFrameConstructor::ContentAppended(aPresContext=0x034f2798,
aContainer=0x03771008, aNewIndexInContainer=0)	C++

and ma8 with this (mHead is 0x00000020, so this is dead):

nsFloatCacheList::~nsFloatCacheList()	C++
nsLineBox::ExtraInlineData::~ExtraInlineData()	C++
nsLineBox::ExtraInlineData::`scalar deleting destructor'()	C++
nsLineBox::Cleanup()	C++
nsLineBox::~nsLineBox()	C++
nsLineBox::`scalar deleting destructor'()	C++
nsLineBox::Destroy(aPresShell=0x033e40c0)	C++
nsLineBox::DeleteLineList(aPresContext=0x0336fd58, aLines={...})	C++
DestroyOverflowLines(aPresContext=0x0336fd58, aFrame=0x0321bff0,
aPropertyName=0x003efe60, aPropertyValue=0x0336f5d8)	C++
nsFrameManager::SetFrameProperty(aFrame=0x0321bff0, aPropertyName=0x003efe60,
aPropertyValue=0x031b1868, aPropDtorFunc=0x01899dc0)	C++
nsFrame::SetProperty(aPresContext=0x0336fd58, aPropName=0x003efe60,
aPropValue=0x031b1868, aPropDtorFunc=0x01899dc0)	C++
nsBlockFrame::SetOverflowLines(aPresContext=0x0336fd58,
aOverflowLines=0x031b1868)	C++
nsBlockFrame::PushLines(aState={...}, aLineBefore={...})	C++
nsBlockFrame::PlaceLine(aState={...}, aLineLayout={...}, aLine={...},
aKeepReflowGoing=0x0012841c, aUpdateMaximumWidth=0)	C++
nsBlockFrame::DoReflowInlineFrames(aState={...}, aLineLayout={...}, aLine={...},
aKeepReflowGoing=0x0012841c, aLineReflowStatus=0x001281af,
aUpdateMaximumWidth=0, aDamageDirtyArea=1)	C++
nsBlockFrame::DoReflowInlineFramesAuto(aState={...}, aLine={...},
aKeepReflowGoing=0x0012841c, aLineReflowStatus=0x001281af,
aUpdateMaximumWidth=0, aDamageDirtyArea=1)	C++
...

Over to dbaron...

Comment 14

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

The latter stack (ma8) in comment 13 looks like bug 265027.  (We shouldn't call
PushLines in non-paginated layout.)

Comment 15

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

Attachment: patch for ma4

Comment 16

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

Comment on attachment 163086 [details] [diff] [review]
patch for ma4

I said I'd do this the next time I saw one of these crashes, and I am.

Comment 17

[Brendan Eich [:brendan]]

Comment on attachment 163086 [details] [diff] [review]
patch for ma4

sr=[e-mail].

/be

Comment 18

[Asa Dotzler [:asa]]

Comment on attachment 163086 [details] [diff] [review]
patch for ma4

a=asa for branch checkins.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 163086 [details] [diff] [review]
patch for ma4

r=bzbarsky.  Those are a pain to track down, indeed....

Comment 20

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

Fix checked in to trunk, 2004-10-22 19:49 -0700.
Fix checked in to AVIARY_1_0_20040515_BRANCH, 2004-10-22 19:50 -0700.
Fix checked in to MOZILLA_1_7_BRANCH, 2004-10-22 19:50 -0700.

(I'm tempted to mark the bug invalid, though, since filing many bugs in one
report makes things almost impossible to track.)

Comment 21

[Daniel Veditz [:dveditz]]

clearing security flag