195073 - Crash on JavaScript-enhanced layer [@ nsTextFrame::PaintAsciiText]

Status: VERIFIED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[Ruud]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030212
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030212

Please visit the URL above and click the Notepad icon, close it, and open it
again. This will crash Mozilla 1.3b.

Reproducible: Always

Steps to Reproduce:
1. Go to http://ip30.eti.uva.nl/ember/ch1_info.php
2. Click Notepad icon, the Notepad layer will appear gradually.
3. Click Hide Notepad
4. Repeat step 2.
5. When Hide Notepad is clicked, this time Mozilla will crash hard.


Actual Results:  
Mozilla crashes.

Expected Results:  
Well...

In the PC the error message "gklayout.dll" is mentioned.

Comment 1

[Tulio Serpio]

In Phoenix 0.5 (Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3a) Gecko/20021207
Phoenix/0.5) works fine.

Comment 2

[Matthias Versen [:Matti]]

Can you please attach a OS X crash log ?

Comment 3

[Ruud]

Attachment: Crash log

The crash does NOT occur in the latest official version (1.2.1)!

Comment 4

[Greg K.]

WorksForMe using FizzillaMach/2003022103. Ruud, can you still reproduce this
problem using a current nightly build? If so, can you reproduce this problem
using another Mozilla user profile?

Comment 5

[Jesiah S]

It crashes on me too.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030224
Talkback ID: TB17529834Y
It took me about two-three open/hide for it to happen.

Comment 6

[Greg K.]

Confirmed using FizzillaMach/2003022103, generating TB177879M.

Comment 7

[Greg K.]

Attachment: Crash report generated by FizzillaMach/2003022103 showing crash at nsTextFrame::PaintAsciiText

This crash report was formatted better for some reason.

Comment 8

[Greg K.]

Setting All/All per comment 5.

Lots of layout stuff on the stack. Let's send this to Layout.

Comment 9

[Boris Zbarsky [:bzbarsky]]

text frame stuff; not JS.

Comment 10

[Greg K.]

Adding regression keyword per comment 3. Should this get fixed for 1.3 final?

Comment 11

[Simon Montagu :smontagu]

Crash is at
http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsTextFrame.cpp#3266

aRenderingContext.SetColor(nsCSSRendering::TransformColor(aTextStyle.mColor->mColor,canDarkenColor));

aTextStyle.mColor is null.

Comment 12

[Hermann Schwab]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030226
DocWatson says:
Trap 0e 0000 invalid page fault
GKLAYOUT.DLL:.text+0x1f595

and some more, but I cant copy&paste it.

Comment 13

[Simon Montagu :smontagu]

 mColor = (const nsStyleColor*) sc->GetStyleData(eStyleStruct_Color); at
http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsTextFrame.cpp#541
is returning nsnull.

Comment 14

[Simon Montagu :smontagu]

Do we want to put in a temporary wallpaper patch to prevent the crash?

Comment 15

[Hermann Schwab]

TB17570589W Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030227
DocWatson told me it´s Mozilla 1.4a ...

Comment 16

[Jan Carpenter]

adding topcrash to keywords
 

Comment 17

[rbs]

-> bryner

From comment 4, it worked up to 2003 02 21. Might be a regression from bryner's
deCOMtamination which landed thereafter on Feb 21. There have been other hiccups
that have since been fixed as well. Let see what he thinks.

Comment 18

[Greg K.]

Note that my comment 4 was in error. I failed to repeat the operation. Once I
did repeat it, FizzillaMach/2003022103 crashed per my comment 6.

Comment 19

[rbs]

Feb 21 was also the day when the tree branched for m1.3, and the deCOMtamination
didn't land on the branch. To narrow the window, can somebody who can test a
build from the branch tell us if they see the bug?

Comment 20

[Greg K.]

The bug was introduced between 1.2.1 (comment 3) and 2003-02-12 (comment 0).

Comment 21

[rbs]

OK, I see. But that window [feb/12/2003 - dec/2002] is still too large though.
It has been my experience that these null style pointers (or dead references)
can be very hard to track down and fix. It would help if the window could be
shrinked to a day. (Actually, one of my radar shows that
nsTextFrame::PaintAsciiText is just paying the price. The style color pointer
becomes null at some earlier stage in the absolute container block, but since
nobody needs the color there...)

Here are the checkins between feb/12/2003 - dec/02/2002, just too much to make
any sense of them. (BTW, I tested that the bug didn't come from any of mine)
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=%2Fmozilla%2F&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=12%2F02%2F2002+04%3A00&maxdate=02%2F12%2F2003+10%3A00&cvsroot=%2Fcvsroot

Comment 22

[Greg K.]

On further experimentation, my comment 20 is in error. This problem was
introduced between 2002-10-30-11-trunk and 2002-11-08-08-trunk.

1.2 probably branched before this happened, which is why 1.2.1 doesn't crash.

Comment 23

[Andrew Schultz]

regression between trunk builds 2002110508 and 2002110604

Comment 24

[rbs]

Checkins between 2002/11/05 and 2002/11/06:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=%2Fmozilla%2F&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=11%2F05%2F2002+04%3A00&maxdate=11%2F06%2F2002+10%3A00&cvsroot=%2Fcvsroot

Comment 25

[Brian Ryner (not reading)]

Could this be glazman's checkin to nsCSSDeclaration.cpp, for bug 172199?  I'm
pretty sure I'm not the right owner for the bug.

Comment 26

[Boris Zbarsky [:bzbarsky]]

Unlikely.... That just changed what the DOM shows, not what the computed style
data is.

This could also be something like bug 74951, I guess.

In any case, I suspect that whatever checkin caused this merely uncovered a
problem -- the problem that we're clearing away style data and then not
necessarily recreating it.  With the patch for bug 171830 I don't crash....

Comment 27

[Jay Patel [:jay]]

Making this topcrash+ and adding testcase keyword since it is easily
reproducible with the steps mentioned in comment #0.

Comment 28

[Andrew Schultz]

Attachment: testcase

now there's a testcase...

Comment 29

[Andrew Schultz]

looks like a dupe of 190558

Comment 30

[rbs]

Marking fixed now that bug 171830 has landed and has resolved the problem.

Noted however that nsBrowserStatusHandler.js::endDocumentLoad() is dumping this
curious message: Error loading URL javascript:openNotepad(); : 805303f5

Comment 31

[Ruud]

I don't know if this was supposed to have been fixed in 1.3 final but with the
OS X version released today I still experience the crash as originally described.

Comment 32

[Andrew Schultz]

> I don't know if this was supposed to have been fixed in 1.3 final

it wasn't.  bug 171830, which fixed this, was never checked into the 1.3 branch.

re-resolving as FIXED

Comment 33

[Madhur Bhatia]

checked the url testcase (comment 0) on winXP, macosX and linux on the latest
trunk nightlies.
no crash see.
Marking verified.