134374 - crash going to file from xul directory listing - Trunk [@ nsTreeBodyFrame::GetImage]

Status: VERIFIED FIXED

(Core :: XUL, defect)

Description

[Bradley Baetz (:bbaetz)]

Go to file:///etc/ on linux, and then try to open a file by double-clicking

This crashes mozilla. I get several assertions of the form:

###!!! ASSERTION: element not in the document: 'doc != nsnull', file
/home/bbaetz/src/mozilla/layout/html/style/src/nsChildIterator.cpp, line 54
###!!! Break: at file
/home/bbaetz/src/mozilla/layout/html/style/src/nsChildIterator.cpp, line 54

Then I crash with:

###!!! ASSERTION: You can't dereference a NULL nsCOMPtr with operator->().:
'mRawPtr != 0', file ../../../../../../dist/include/xpcom/nsCOMPtr.h, line 650
###!!! Break: at file ../../../../../../dist/include/xpcom/nsCOMPtr.h, line 650
nsDebug::Assertion(char const *, char const *, char const *, int)+0x00000096
[/home/bbaetz/src/objdir/dist/bin/libxpcom.so +0x0011A696]
nsDebug::PreCondition(char const *, char const *, char const *, int)+0x00000022
[/home/bbaetz/src/objdir/dist/bin/libxpcom.so +0x0011A9C6]
nsTreeBodyFrame::GetImage(int, unsigned short const *, int, nsIStyleContext *,
imgIContainer **)+0x0000069E
[/home/bbaetz/src/objdir/dist/bin/components/libgklayout.so +0x0031ECF6]
nsTreeBodyFrame::GetImageSize(int, unsigned short const *, int, nsIStyleContext
*)+0x0000015C [/home/bbaetz/src/objdir/dist/bin/components/libgklayout.so
+0x0031F918]
nsTreeBodyFrame::PaintImage(int, nsTreeColumn *, nsRect const &, nsIPresContext
*, nsIRenderingContext &, nsRect const &, nsFramePaintLayer, int &, int
&)+0x00000195 [/home/bbaetz/src/objdir/dist/bin/components/libgklayout.so
+0x003236B5]
nsTreeBodyFrame::PaintCell(int, nsTreeColumn *, nsRect const &, nsIPresContext
*, nsIRenderingContext &, nsRect const &, nsFramePaintLayer)+0x00000D5F
[/home/bbaetz/src/objdir/dist/bin/components/libgklayout.so +0x003228EF]

at the top of the stack. This is a -O2 debug build, so I can't get any more
detail than that.

Is this related to moz-icon (which is used in the xul viewer) not being
implemented on linux?

The XUL dir viewer is going to be removed for 1.0, so I won't mind if you future
this unless you can repro it in other cases, or its just a simple null check for
image not found.

Comment 1

[Arthur]

WorksForMe on linux 2002032808. Which build are you using?

Comment 2

[Bradley Baetz (:bbaetz)]

I'm using current CVS. You need something after hewitt's checkin - 20020328 is
too old.

Comment 3

[André Dahlqvist]

I can confirm this with 2002-03-30-10. It also crashes if I double-click on a
folder. I used /home/andre/ as a test in my Linux box.

Comment 4

[Olav Vitters]

Attachment: Another stacktrace, CVS linux today

Attaching my stacktrace. I got the same assertions before crashing. Seems to be
more detailed although this is a -O3 debug build (why?).

Comment 5

[Bradley Baetz (:bbaetz)]

My stacktrace wasn't done with gdb, it was done with XPCOM_DEBUG_BREAK=stack.

Comment 6

[André Dahlqvist]

Talkback ID: TB4658089E

Nominating for mozilla 1.0 as this would make that suck.

Comment 7

[Matthias Versen [:Matti]]

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

Comment 8

[Krishnakumar B]

I am also seeing this under Linux i686 BuildId 2002040108.

Comment 9

[Jay Patel [:jay]]

Adding topcrash keyword and updating summary with Trunk [@
nsTreeBodyFrame::GetImage]...there are quite a few of these crashes with recent
MozillaTrunk builds:

nsTreeBodyFrame::GetImage   17 
BBID range: 4657780 - 4713307
Min/Max Seconds since last crash: 15 - 63274
Min/Max Runtime: 44 - 64267
Crash data range: 2002-03-31 to 2002-04-01
Build ID range: 2002032911 to 2002040108
Keyword List : 
Stack Trace: 

	 nsTreeBodyFrame::GetImage()
	 nsTreeBodyFrame::GetImageSize()
	 nsTreeBodyFrame::PaintImage()
	 nsTreeBodyFrame::PaintCell()
	 nsTreeBodyFrame::PaintRow()
	 nsTreeBodyFrame::Paint()
	 PresShell::Paint()
	 nsView::Paint()
	 nsViewManager::RenderDisplayListElement()
	 nsViewManager::RenderViews()
	 nsViewManager::Refresh()
	 nsViewManager::DispatchEvent()
	 HandleEvent()
	 nsWidget::DispatchEvent()
	 nsWidget::DispatchWindowEvent()
	 nsWindow::DoPaint()
	 nsWindow::Update()
	 nsWindow::UpdateIdle()
	 libglib-1.2.so.0 + 0x1279d (0x4038d79d)
	 libglib-1.2.so.0 + 0x11773 (0x4038c773)
	 libglib-1.2.so.0 + 0x11d39 (0x4038cd39)
	 libglib-1.2.so.0 + 0x11eec (0x4038ceec)
	 libgtk-1.2.so.0 + 0x94333 (0x402a8333)
	 nsAppShell::Run()
	 nsAppShellService::Run()
	 main1()
	 main()
	 libc.so.6 + 0x1c507 (0x404d3507)     (4705898)	Comments: tried to open a png-file
     (4666380)	Comments: GRRR!
     (4665810)	Comments: Double clicking on _any_ file in a file: -filelist seems to crash
(fourth).
     (4665794)	Comments: Going to file:///tmp/ and double-clicking on the dir "dogs" -
third crash in a row  it doesn't seem related to dirs with spaces in them.
     (4665780)	Comments: Went to file:///tmp/ - double clicked on the dir "New Finals".
(This is reproducing my previous crash).
     (4665777)	URL: file:///local/home/y/phil/Locke-iep.html
     (4665777)	Comments: First I loaded the directory (file:///local/home/y/phil/)  and
then selected theabove file from the directory list.  As soon as I did  mozilla
crashed.
     (4665619)	Comments: Opening a file:///-path (with a space in it  I don't know if that
was significant though).
     (4658153)	Comments: Crash when double-clicking on a folder in my home directory.100%
reproducable.
     (4658089)	URL: /home/andre/index.html
     (4658089)	Comments: Steps to reproduce:1) Type your home directory eg /home/yourname
in the location bar.2) Find a .html-file in there.3) Double-click on
it.CRASH.This is bug 134374.
     (4657780)	Comments: 1. launch mozilla.display: an empty page2. input /mnt/dev/book/ in
the url bar and press Enter.display: there are four directories named in
chinese(gb2312 encoding).they are all folded.3. click on the "expand" icon to
unfold the directorydisplay:
     (4657780)	Comments:  the directory is unfolded and some html files below them are
listed.4. click on one of these filesdisplay: mozilla crashed.

Also adding qawanted to get this reproduced in-house and nominating for nsbeta1.

Comment 10

[Jay Patel [:jay]]

This crash was introduced in builds from 3/29 according to Talkback data.

Comment 11

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

Attachment: one way to fix this

This is (yet again) the notorious GetDocument returns null during page teardown
bug.  (And yes, this bug has been driving me crazy for a few days now, and
forcing me to attach untested HTML testcases to bugzilla so I could view them. 
I finally just spent 2 minutes in gdb and fixed it.)

So this patch is the lazy way to fix it.  We could also do the
nsIContent->nsIDOMNode-[GetOwnerDocument]->nsIDOMDocument->nsIDocument dance if
you think it's worth the bother.  I'm still looking to see what was changed
when the file was copied.

Comment 12

[sairuh (rarely reading bugmail)]

test cases (using 2002.04.03.14 comm verif bits):

* double-click folder name (reliable for me, so far)
* double-click filename that's in an expanded folder (sometimes occurs)

shrir, i'll take this off your hands, if you don't mind...

Comment 13

[Scott Collins]

Comment on attachment 77383 [details] [diff] [review]
one way to fix this

sr=scc

Comment 14

[Jay Patel [:jay]]

Making topcrash+ and adding testcase keyword...since sairuh has steps to repro
and we have a patch ready.

Comment 15

[Asa Dotzler [:asa]]

Comment on attachment 77383 [details] [diff] [review]
one way to fix this

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

Comment 16

[Jaime Rodriguez, Jr.]

adt1.0.0+ (on ADT's behalf) approval for checkin into 1.0.

Comment 17

[timeless]

Comment on attachment 77383 [details] [diff] [review]
one way to fix this

committed

Comment 18

[Heikki Toivonen (remove -bugzilla when emailing directly)]

In other words, fixed. Thanks.

Comment 19

[Samir Gehani]

Nav triage team: nsbeta1+/adt2

Comment 20

[André Dahlqvist]

I can double click on a .html file in my home directory without mozilla
crashing, and double clicking on a folder works as well.

VERIFIED FIXED with 2002-04-05-18 on Linux.

Comment 21

[Bradley Baetz (:bbaetz)]

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