some more crashes detected by mangler.cgi

RESOLVED FIXED in mozilla1.8alpha5

Status

()

defect
--
critical
RESOLVED FIXED
15 years ago
13 years ago

People

(Reporter: guninski, Assigned: dbaron)

Tracking

({crash, fixed-aviary1.0, fixed1.7.5})

Trunk
mozilla1.8alpha5
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [patch])

Attachments

(4 attachments, 3 obsolete attachments)

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:
Posted file ma3.html (obsolete) —
ma3.html
Posted file ma4.html
ma4.html
Posted file ma5.html (obsolete) —
ma5.html
Posted file ma6.html (obsolete) —
ma6.html
Posted file ma8main.html
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.
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?
Assignee: general → nobody
Blocks: Zalewski
Component: Browser-General → Layout
QA Contact: general → core.layout
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 on attachment 162824 [details]
ma3.html

WFM now (most likely fixed by bug 264956).
Attachment #162824 - Attachment is obsolete: true
Comment on attachment 162827 [details]
ma5.html

WFM now (most likely fixed by bug 264956).
Attachment #162827 - Attachment is obsolete: true
Comment on attachment 162828 [details]
ma6.html

WFM now (most likely fixed by bug 264956).
Attachment #162828 - Attachment is obsolete: true
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...
Assignee: nobody → dbaron
Flags: blocking-aviary1.0?
OS: Linux → All
Hardware: PC → All
The latter stack (ma8) in comment 13 looks like bug 265027.  (We shouldn't call
PushLines in non-paginated layout.)
Depends on: 265027
No longer depends on: 65027
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.
Attachment #163086 - Flags: superreview?(brendan)
Attachment #163086 - Flags: review?(bzbarsky)
Attachment #163086 - Flags: approval1.7.x?
Attachment #163086 - Flags: approval-aviary?
Whiteboard: [patch]
Target Milestone: --- → mozilla1.8alpha5
Comment on attachment 163086 [details] [diff] [review]
patch for ma4

sr=brendan@mozilla.org.

/be
Attachment #163086 - Flags: superreview?(brendan) → superreview+
Comment on attachment 163086 [details] [diff] [review]
patch for ma4

a=asa for branch checkins.
Attachment #163086 - Flags: approval1.7.x?
Attachment #163086 - Flags: approval1.7.x+
Attachment #163086 - Flags: approval-aviary?
Attachment #163086 - Flags: approval-aviary+
Comment on attachment 163086 [details] [diff] [review]
patch for ma4

r=bzbarsky.  Those are a pain to track down, indeed....
Attachment #163086 - Flags: review?(bzbarsky) → review+
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.)
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Updated

15 years ago
Flags: blocking-aviary1.0?
clearing security flag
Group: security
Severity: normal → critical
Keywords: crash
You need to log in before you can comment on or make changes to this bug.