105619 - Javascript menus crash mozilla 0.9.5 & CVS [@ CopyChars1To2][@ FrameManager::ReResolveStyleContext] [@ nsAString::do_AssignFromReadable][@ nsAString::AssignFromReadable]

Status: VERIFIED FIXED

(Core :: CSS Parsing and Computation, defect, P1)

Description

[Mikael Nilsson]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5+) Gecko/20011017
BuildID:    2001101715

When trying to pop down a javascript menu on our
BSCW server, Mozilla crashes instantly.

This is a problem with both 0.9.5 and the 2001101715 CVS version
from Debian unstable.

It worked on 0.9.4 and before.

Reproducible: Always
Steps to Reproduce:
1. Go to http://ulldb.ull.uu.se/matdid/pub/bscw.cgi/0/4
2. Click on "File"
3. Crash

Actual Results:  Mozilla crashes instantly

Expected Results:  A pop-down menu should have appeared.

Comment 1

[R.K.Aa.]

TB36901281E

Comment 2

[R.K.Aa.]

The crash occures already on mousing over the "File" menu at that site.
There's an older (fixed) bug 91479 with the same stack. I added comment there.
Resolving as new, adding to summary. Unsure about component..

#0  0x4015dfd3 in CopyChars1To2 () at eval.c:41
#1  0x4015ec8b in nsStr::StrAppend () at eval.c:41
#2  0x4015ebc9 in nsStr::StrAssign () at eval.c:41
#3  0x40161ff1 in nsString::nsString () at eval.c:41
#4  0x40026b23 in nsFont::nsFont () at eval.c:41
#5  0x41293fc2 in nssArenaHashAllocOps () from
/usr/local/mozilla/components/libgfx_gtk.so
#6  0x400268b6 in nsFontCache::GetMetricsFor () at eval.c:41
#7  0x40025c84 in DeviceContextImpl::GetMetricsFor () at eval.c:41
#8  0x417a72df in NSGetModule () from /usr/local/mozilla/components/libgklayout.so
......

Comment 3

[timeless]

moving to strings, probably belongs to fonts (which doesn't exist as a
component, layout?)

Comment 4

[Marc Attinasi]

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

Comment 5

[kill this account]

I'd guess it is this line:

http://lxr.mozilla.org/seamonkey/source/gfx/src/nsFont.cpp#46

 42 nsFont::nsFont(const char* aName, PRUint8 aStyle, PRUint8 aVariant,
 43                PRUint16 aWeight, PRUint8 aDecoration, nscoord aSize,
 44                float aSizeAdjust)
 45 {
 46   name.AssignWithConversion(aName);

which has not charged for a while:

  3.9 <[e-mail]> 03 Apr 2000 01:27
      making string conversions explicit

Could this be a null pointer?

(my unix systems here at netscape are still horked from the network upgrade)

Comment 6

[rbs]

I seem to recollect that name.AssignWithConversion(nsnull) is (or should I say,
used to be?) designed not to crash. It amounts to name.SetLength(0).

Comment 7

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

Anyway, that stack makes it look like it's crashing in the string's constructor,
not AssignWithConversion.  Maybe some memory is corrupt?

Comment 8

[Markus Hübner]

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

Comment 9

[John Bandhauer]

I'm not sure I'm happy with dumping these dups on scc. I question whether the 
string code is at fault here.

Please note my comment http://bugzilla.mozilla.org/show_bug.cgi?id=108240#c4
For whatever reason it looks like we're getting a font with a garbage string 
from a style context.

Who is going to actually dig this out and solve it?

Comment 10

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

The URL given, http://ulldb.ull.uu.se/matdid/pub/bscw.cgi/0/4 , is currently
giving me a 404 so I can't reproduce the crash.

Comment 11

[John Bandhauer]

I get a 404 too. The dup'd bug 108240 still crashes for me on W2K. Let's be 
careful this chain of dup's does not get closed because we can't reproduce this 
one case :)

Comment 12

[rbs]

It is crashing because the data that is stored in 
nsStyleContext::mCachedStyleData becomes corrupted at some point (maybe somebody 
is overwriting it). I made a little patch to inspect if the font data that is 
read from the style context has indeed be set earlier. 

I see a pattern like
>>Set the data in the style context
> [set other data]
>>Get the data <- OK
> [get other data]
> [set other data]
>>Get the data <- might be OK for some time 
> [get other data]
> [set other data]
>>Get the data <- becomes corrupted at some point, causing the crash
(For information, I will attach the little patch that I used for this.)

Updating URL and adding the regression keyword since it works in m0.9.5.
(qawanted might be needed to narrow the window of faulty builds).

Re-assigning to the Style System to kick off the investigation from there.

Comment 13

[rbs]

Attachment: FYI - patch used for inspection - includes explanatory comments

Comment 14

[Mikael Nilsson]

Sorry, our BSCW server moved, so the URL I gave no longer works.

Try instead (same crash):

https://kmr.nada.kth.se/pub/bscw.cgi
/Mikael

Comment 15

[Markus Hübner]

https://kmr.nada.kth.se/pub/bscw.cgi doesn't crash on win2k using build 
2001111108.
Could the reported crash at this URL be related to bug 107850 ?

Comment 16

[Mikael Nilsson]

Mozilla CVS from 2001110816 on Debian unstable no longer crashes. Has this bug
been fixed?

Comment 17

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

hyatt, any thoughts?

Comment 18

[David Bradley]

Talking with matic we discovered a similar stack trace in talk backs. There are
67 incidents that end in CopyChars1To2. In a small sampling the following
appears to be more prevelant than the stack trace reported earlier in this bug.
Talkback ID 38095137 contains this stack if someone wants to look at that.

CopyChars1To2()
nsStr::StrAppend()
nsString::AppendWithConversion()
nsString::AssignWithConversion()
nsPlainTextSerializer::AppendText()

Comment 19

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

That's the stack you get when someone tries to append (to?) a bogus string.  It
shouldn't all be lumped into one bug.

Comment 20

[David Bradley]

Ok, then about 20% of 67 talkback incidents appear to be related to this bug.
That from about a sampling of 10 of the 67 bugs.

Comment 21

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

Attachment: patch that ought to fix the crash (still need to test where I can reproduce)

Comment 22

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

Well, it didn't seem to help.  Either that, or I'm running into a different
crash (I was seeing two different ones before).  I did notice a typo, which is
that I had mChild in one place where I should have had mEmptyChild.

Comment 23

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

Attachment: patch fixing two mistakes in previous patch

There was another problem in addition to the mEmptyChild problem -- I need to
pass  |~PRUint32(0)|, not |bitsToClear|, since ClearStyleData clears all the
data from a style context, not just the data it inherits.

Comment 24

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

Well, it still doesn't work, and I don't know why.

(If I do get it to work, in my tree I've renamed the new function to
nsStyleContext::ClearInheritedData(PRUint32 aBitsClearedFromParent), and it
could probably even be combined with ClearStyleData.)

Comment 25

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

Attachment: more-cleaned-up version of patch which I think is correct but unrelated to this bug

Comment 26

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

In the debugger, I found that all the calls to ClearStyleData before the crash
set |matched| to false, so they wouldn't cause the crash.

Comment 27

[rbs]

+void nsStyleContext::ClearInheritedData(PRUint32 aBitsClearedFromParent)
+{
+  PRUint32 bitsToClear = aBitsClearedFromParent & mBits;
+  if (bitsToClear) {

It seems this is not covering all the cases. Suppose a direct child is not
inhereting anything, but the grandchild is inheriting something. Then
bitsToClear <- 0 for the child, and so the grandchild won't be visited. Or is
this case an impossible case?

Comment 28

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

The grandchild would be inheriting from the child, and since we're not clearing
the data out of the child there's no need to clear it out of the grandchild.

Though actually, now that I think about it, even if a child isn't inheriting the
entire struct, parts of the struct could be invalid and we should probably clear
the whole thing anyway.  Or am I missing something?

Comment 29

[rbs]

Currently, as soon as |matched| happens to be true, the whole subtree is blown 
away (by virtue of the recursive call to ClearStyleData() with the param |aRule| 
forced to nsnull). So invalidations seem to be taking no chances already.

Comment 30

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

Comment on attachment 59128 [details] [diff] [review]
more-cleaned-up version of patch which I think is correct but unrelated to this bug

ah, good, then.

Comment 31

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

I missed that little uncommented |aRule = nsnull| that was the key to the entire
function.  So now I'm back to having no idea at all how we could get into this
state...

Comment 32

[rbs]

Some clues that might be useful. I tried to following experiments:
1) In nsCSSFrameConstructor::AttributeChanged(), I forced the hint to be set as
|reconstruct| if if was |restyle|, i.e.:
[...]
 if (restyle) {
   restyle = PR_FALSE;
   reconstruct = PR_TRUE;
 }
[...]
Motivation: it the style tree is corrupted, let's see what happens if the whole 
document hierarchy is reconstructed anyway... Unfortunately, this generated lots 
of assertions with XBL frames, although HTML frames could withstand this and I 
eventually managed to display the testcase using viewer without scrollbars. (The 
scroball code was crashing and I had to add an early return in 
nsGfxScrollFrameInner::AddRemoveScrollbar() to stop them from being created at 
all.) 

2) Back to a fresh tree, in nsDOMCSSAttributeDeclaration::ParsePropertyValue(),
I tried commenting the line [hint = 0]:
//result = cssParser->ParseProperty(aPropName, aPropValue, baseURI, decl,&hint);
Motivation: there are several |style| attributes in the testcase, let see if
the problem comes from one of them. With this line commented out, the tescase 
could render with Mozilla (and viewer).

So, going on from there, I dumped:

+nsCAutoString prop; prop.Assign(NS_ConvertUCS2toUTF8(aPropName));
+nsCAutoString value; value.Assign(NS_ConvertUCS2toUTF8(aPropValue));
+printf("Content:%p Prop:%s value:%s\n", mContent, prop.get(), value.get());
 result = cssParser->ParseProperty(aPropName, aPropValue, baseURI, decl, &hint);

This gave the following output on the debug console:

Content:02FBDCF0 Prop:visibility value:hidden
Content:02FBEEE0 Prop:visibility value:visible
Content:02FC76C0 Prop:display value:none
Content:02FC5440 Prop:visibility value:hidden
Content:02FDB140 Prop:display value:block
Content:02FC5440 Prop:visibility value:visible
Content:02FDB140 Prop:display value:none
Content:02FC5440 Prop:visibility value:hidden
Content:02FDB140 Prop:display value:block
Content:02FC5440 Prop:visibility value:visible
Content:02F71990 Prop:top value:75
->crash -- invariably happens here after the above sequence.

Continuing... I wondered what might happen if the last prop is ignored... i.e.,

+if (!aPropName.Equals(NS_LITERAL_STRING("top")))
  result = cssParser->ParseProperty(aPropName, aPropValue, baseURI, decl, 
&hint);

But this only delayed the crash, which now happened because of an index
  PRInt32 i = mFormControls.Count(); /* = 50806944 -- see stack trace !! */

nsVoidArray::ElementAt(int 50806943) line 373 + 9 bytes
nsFormFrame::AddFormControlFrame(...) line 358 
nsFormFrame::AddFormControlFrame(...) line 193
nsHTMLButtonControlFrame::SetInitialChildList(nsHTMLButtonControlFrame * ...)
nsCSSFrameConstructor::ConstructFrameByTag(...)
nsCSSFrameConstructor::ConstructFrameInternal(...)
nsCSSFrameConstructor::ConstructFrame(...)
[...]

At that point, I gave up... thinking that I might do something else.

Comment 33

[Samuel Sieb]

I was tracking down a crasher bug in a different page and I wondered if there
was something similar already reported.  This looks to be the same issue.  What
I found is that a nsFontStruct is being reused after being freed.  So the .name
in the nsFont is garbage, so usually you don't get CopyChars1To2 because the
charSize is 38 or something, so it just crashes.

Comment 34

[rubydoo123]

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

Comment 35

[rbs]

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

Comment 36

[Ron Thigpen]

Talkback IDs from Bug 112311, which is currently marked as a duplicate of this
(105619).

TB38567098Z
TB38567053M
TB38567005M

--rt

Comment 37

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

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

Comment 38

[Matthias Versen [:Matti]]

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

Comment 39

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

stephend -- Any chance you could try loading http://www.iht.com/frontpage.htm
under Purify?  I'd be especially interested to see the stack traces associated
with any FMR or FMW (both the stacks for the free and for the FMR/FMW).

Comment 40

[kill this account]

I'm building on sheep but it very slow and I may run out of time today.

Comment 41

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

stephend sent me a purify log, but it wasn't very useful, since it just showed a
null pointer dereference

Comment 42

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

Attachment: simplified testcase

Comment 43

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

I think what's happening here is that the style context from which we're getting
the bad data has actually been destroyed (we never call the destructor, so it
still has a valid vtable pointer, even on Windows), and the frame has been
destroyed as well (bad vtable pointer, though, but GetStyleContext is inline). 
I think somehow there are stale frames in the primary frame map, perhaps because
we're not observing frame destructions yet during the onload handler or
something like that.

Comment 44

[Marc Attinasi]

My fix for bug 97874 may have fixed this problem. RBS pointed me to this bug,
and I tested the testcase and http://www.iht.com/frontpage.htm with my local
build and it did not crash. Might be worht applying the simple patch from bug
97874 to see if it does indeed fix this problem.

Comment 45

[John Morrison]

Nope, I still crash with the patch from 97874. Oh, vell.

Comment 46

[Jay Patel [:jay]]

Might this be a regression of bug 91479?  That bug has a similar stack to the
ones reported here.

Comment 47

[Johnny Stenback (:jst)]

David, we also have other bugs where we get stale frame pointers out of the
frame map, so that could definately be it. Don't know what those bugs are tho,
IIRC I gave one to attinasi a while back.

Comment 48

[Samuel Sieb]

The testcase gives me a completely different stack trace than the original page.

Comment 49

[Ashley Bischoff (blog at handcoding.com)]

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

Comment 50

[Oscar van Vliet]

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

Comment 51

[Jay Patel [:jay]]

Adding [@ FrameManager::ReResolveStyleContext] to summary since bug 111061 was
marked a dup and that crash is a topcrasher on recent MozillaTrunk builds as well.

Comment 52

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

Once I get bug 110911 checked in I'll try to instrument the primary frame map
with PR logging so that I can figure out what isn't being removed.  Until then,
it's difficult since I don't want to get conflicting changes.

Comment 53

[Oscar van Vliet]

Here's five talkback IDs from bug 112819. Thanks for the hot attention. This bug
sucks badly - I have to go back to NS4.7 for my daily news updates.

TB38704567X
TB38704525Q
TB38504540W
TB38504451W
TB38504351W

Comment 54

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

So, I had been hoping that, even though the symptoms of the crash on the
simplified testcase were different, the underlying reason was the same.  That
turns out not to be the case.  The crash in the minimal testcase is fixed by my
patch on bug 110911.  I think DST node removal is broken in some way, or
something like that.  However, I didn't see any cases in http://www.iht.com/
where we were leaving deleted primary frames in the map.

So I need to simplify the testcase again in a build with my bug 110911 changes...

Comment 55

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

So it turns out my nsDST removal didn't really fix the problem in the simplified
testcase -- it just hid it so it doesn't crash.  The following assertion fires
on that testcase:

Index: nsFrameManager.cpp
===================================================================
RCS file: /cvsroot/mozilla/layout/html/base/src/nsFrameManager.cpp,v
retrieving revision 1.94
diff -u -r1.94 nsFrameManager.cpp
--- nsFrameManager.cpp  6 Dec 2001 05:45:01 -0000       1.94
+++ nsFrameManager.cpp  6 Dec 2001 21:56:20 -0000
@@ -972,6 +972,16 @@
   mPresShell->GetPresContext(getter_AddRefs(presContext));

   RemoveAllPropertiesFor(presContext, aFrame);
+
+#ifdef DEBUG
+  nsCOMPtr<nsIContent> content;
+  aFrame->GetContent(getter_AddRefs(content));
+  PrimaryFrameMapEntry *entry = NS_STATIC_CAST(PrimaryFrameMapEntry*,
+      PL_DHashTableOperate(&mPrimaryFrameMap, content, PL_DHASH_LOOKUP));
+  NS_ASSERTION(!PL_DHASH_ENTRY_IS_BUSY(entry),
+               "frame not removed from primary frame map before destruction");
+#endif
+
   return NS_OK;
 }

Comment 56

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

The assertion line should really be:

+  NS_ASSERTION(!PL_DHASH_ENTRY_IS_BUSY(entry) || entry->frame != aFrame,

Comment 57

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

The reason we're getting bad frames in the primary frame map is because they're 
getting readded after they're removed due to a call to GetPrimaryFrameFor:

FrameManager::GetPrimaryFrameFor(FrameManager * const 0x04fdb8b0, nsIContent * 
0x043a69c8, nsIFrame * * 0x0012c8f4) line 599
PresShell::GetPrimaryFrameFor(const PresShell * const 0x040ddf38, nsIContent * 
0x043a69c8, nsIFrame * * 0x0012c8f4) line 5315 + 32 bytes
nsGenericHTMLElement::GetPrimaryFrame(nsIHTMLContent * 0x043a69c8, 
nsIFormControlFrame * & 0x00000000, int 0, int 0) line 2794
nsHTMLInputElement::SetValueSecure(nsHTMLInputElement * const 0x043a69c8, const 
nsAString & {...}, int 0) line 518 + 17 bytes
nsHTMLInputElement::SetValueGuaranteed(nsHTMLInputElement * const 0x043a69fc, 
const nsAString & {...}) line 482
nsGfxTextControlFrame2::SetTextControlFrameState(const nsAString & {...}) line 
3410
nsGfxTextControlFrame2::Destroy(nsGfxTextControlFrame2 * const 0x050da630, 
nsIPresContext * 0x04004928) line 1389
nsLineBox::DeleteLineList(nsIPresContext * 0x04004928, nsLineList & {...}) line 
292
nsBlockFrame::Destroy(nsBlockFrame * const 0x050da4c4, nsIPresContext * 
0x04004928) line 327 + 16 bytes

We could try to fix these callers or we could move the removal from the frame 
map to NotifyDestroyingFrame.  I'm going to try the latter right now to see if 
it fixes the real testcase as well, or just the simplified one.

Comment 58

[Johnny Stenback (:jst)]

Doesn't the frame manager know that the frame model is being torn down? Couldn't
it simply not add frames to the frame map in that case? Or is this about
specific frames being torn down, and not the whole frame model?

As for nsHTMLInputElement::SetValueGuaranteed(), we could also make it take a
frame pointer which would let the frame code pass in the frame whenever it calls
that method, and thus the nsHTMLInputFrame wouldn't need to do the frame lookup
when being called from the frame code.

Comment 59

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

I sat down with hyatt to figure out the real cause of the crash.  The root of
the problem is in a style context that inherits an entire struct from a parent
that is using data cached in the rule tree.  Then, when we manipulate the style
attribute on the parent, we blow away the rule node's data and expect the
children style contexts to have valid data until they destroy their old style
contexts in the re-resolve.  Patch coming up.  I'll also attach the patch I used
that allows running with FreeFrame marking memory with 0xdd.

Comment 60

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

Attachment: patch fixing this bug

Comment 61

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

Attachment: patch preventing frame access after deletion (and some other cleanup)

Comment 62

[Oscar van Vliet]

I'm glad to see this is (almost) fixed but I have little question. The IHT
crashes that were dupped to this bug did not exist in 0.9.5. That started in
0.9.6. SO something must have regressed in the 095-096 time. Why the difference?

Of course, if it works again, you won't hear me complain. Just on the off chance
this won't entirely fix it :).

Comment 63

[Minko Markov]

[e-mail]:
> I'm glad to see this is (almost) fixed but I have little question. The IHT
> crashes that were dupped to this bug did not exist in 0.9.5. That started in
> 0.9.6. SO something must have regressed in the 095-096 time. Why the
> difference?

It did not start with 0.9.6.  I reported the bug with iht.com, the build
was 2001110112. This was bug report 108240. At that time I downloaded a new
build every morning (I think, not 100% sure it was *every*...), so I can say
(almost) accurately that this was the first build that crashed at IHT. The 
build from the previous day did not crash there -- at that time I used to
check how the nightlies handle iht.com, because of another bug with the
back/forward buttons.

Comment 64

[David Hyatt]

Comment on attachment 60747 [details] [diff] [review]
patch fixing this bug

sr=hyatt

Comment 65

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

Comment on attachment 60748 [details] [diff] [review]
patch preventing frame access after deletion (and some other cleanup)

This patch has been split into bug 114219, bug 114220, bug 114221, and bug
114222

Comment 66

[Mike Shaver (:shaver emeritus)]

Comment on attachment 60747 [details] [diff] [review]
patch fixing this bug

r=shaver

Comment 67

[John Keiser (jkeiser)]

To the poster worried about when this happened: that was the exact date of the
huge bug 34297 patch.  I exposed this bug and created a few of my own.

Comment 68

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

Attachment 60747 [details] [diff] checked in 2001-12-08 14:46 PDT.  Other issues are split into
other bugs as mentioned in comment 65 and other dependencies to bug 114219.

Comment 69

[Markus Hübner]

just crashed with build 2001121003 on win2k!
TB324891G

Comment 70

[greer]

Attachment: Stack from Talkback incident 324891

Here is the talkback stack from comment #69 above. Doesn't look like the same
animal.

Comment 71

[John Morrison]

note the 'JS_ReportOutOfMemory ' in the stack for comment 69 (and it is a 
different bug/crash).

However, this was reproducible in a 12/10 build on win2k, but not with today's
12/11 build on win2k.

Comment 72

[Adam Hauner]

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

Comment 73

[Christopher Aillon (sabbatical, not receiving bugmail)]

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

Comment 74

[kill this account]

Attachment: purify info 2001-12-20 solaris build

Comment 75

[kill this account]

Attachment: purify log file (*.pv)

this is the full purify log

Comment 76

[kill this account]

oops, I forgot to say:

 "it crashed" on the url http://www.iht.com/frontpage.htm

Comment 77

[rbs]

Comment on attachment 62581 [details]
purify info 2001-12-20 solaris build

If aFont contains garbage, then it is no surprise that font creation will fail.

Comment 78

[Yanko Kaneti]

there might still be problems with www.iht.com

http://bugzilla.gnome.org/show_bug.cgi?id=67856

I personally got again a crash in  CopyChars1To2, although not immediately
entering the site, but after some clicking around
(mozilla 0.9.7)

Comment 79

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

Reopening, but since I can't reproduce the bug I'm unlikely to be able to do
anything about it.  Does it crash for some people but not others?  If so, what
determines whether it crashes?  Is there somebody else who could own this bug?

Comment 80

[Yanko Kaneti]

here is a crash snippet i got directly when opening www.iht.com in TestGtkEmbed
compiled against 0.9.7, its reproducable here

#0  0x40364a46 in nsAString::Cut () from /usr/lib/libxpcom.so
#1  0x4037356e in nsStr::StrAppend () from /usr/lib/libxpcom.so
#2  0x403734b1 in nsStr::StrAssign () from /usr/lib/libxpcom.so
#3  0x40376831 in nsString::nsString () from /usr/lib/libxpcom.so
#4  0x407d9853 in nsFont::nsFont () from /usr/lib/libgkgfx.so
#5  0x40831b9f in NSGetModule () from /usr/lib/mozilla/components/libgfx_gtk.so
#6  0x407d941d in nsFontCache::GetMetricsFor () from /usr/lib/libgkgfx.so
#7  0x407d87c8 in DeviceContextImpl::GetMetricsFor () from /usr/lib/libgkgfx.so
#8  0x40e6ee1f in NSGetModule ()
   from /usr/lib/mozilla/components/libgklayout.so
....


looks like something completely different but, hey,  i dont know :) i can file a
different bug  if required

Comment 81

[Yanko Kaneti]

ahm, sorry for the spam, but did more testing

the crash at initial loading of www.iht.com went away after i removed
~/.TestGtkEmbed

but then after some heavy clicking and scrolling while marveling at the dynamic
menubar it crashed again with the same backtrace

tried running it again and opening iht, crashed while loading it again, this was
repeatable until i removed again ~/.TestGtkEmbed

then tried causeing this again, heavy clicking and scrolling and got this:

#0  0x403729c3 in CopyChars1To2 () from /usr/lib/libxpcom.so
#1  0x4037356e in nsStr::StrAppend () from /usr/lib/libxpcom.so
#2  0x403734b1 in nsStr::StrAssign () from /usr/lib/libxpcom.so
#3  0x40376831 in nsString::nsString () from /usr/lib/libxpcom.so
#4  0x407d9853 in nsFont::nsFont () from /usr/lib/libgkgfx.so
#5  0x40831b9f in NSGetModule () from /usr/lib/mozilla/components/libgfx_gtk.so
#6  0x407d941d in nsFontCache::GetMetricsFor () from /usr/lib/libgkgfx.so
#7  0x407d8841 in DeviceContextImpl::GetMetricsFor () from /usr/lib/libgkgfx.so
#8  0x4083f69d in NSGetModule () from /usr/lib/mozilla/components/libgfx_gtk.so
#9  0x40f56b27 in NSGetModule ()
   from /usr/lib/mozilla/components/libgklayout.so

....

it fairly random now and i cant see too much patter in it :(

Comment 82

[Oscar van Vliet]

I am also getting random crashes with the www.iht.com, on the opening page AFAICT.

Talkback IDs:
1625876W
1434967M

I can't be sure that these are caused by the old problem but since this was
reopened, I hope these can shed some light

Comment 83

[Markus Hübner]

Also crashing with build 2002012203 on winxp.
TB1972641K

Comment 84

[greer]

Attachment: Stacks for incidents in Comments 82 & 83

The above stacks look like they belong to bug 106341.

Comment 85

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

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

Comment 86

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

The duplicates of bug 106341 have a number of other ways to reproduce what may
(or may not) be the same problem, but they'd all already been marked duplicates
of bug 106341 because the stack was the same.

Comment 87

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

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

Comment 88

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

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

Comment 89

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

Attachment: debugging notes for http://www.iht.com/

This shows the problem seems pretty similar to what it was before, but actually
with a less unusual situation (a rule node that fully specifies an inherited
struct by specifying the 'font' shorthand property, presumably) then the one I
saw in the debugger when I was able to see this problem on Windows (explicit
inherit on a reset struct).  I wonder why it regressed.

Comment 90

[David Anderson]

Bug 121129 is a duplicate of Bug 106341, Bug 106341 is a duplicate of this bug;
so, then, 121129 is a duplicate of this Bug, eh?

Comment 91

[R.K.Aa.]

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

Comment 92

[Jay Patel [:jay]]

adding [@ nsAString::do_AssignFromReadable][@ nsAString::AssignFromReadable] to
summary for tracking...since bug 106341 was marked a dup.

Comment 93

[Oscar van Vliet]

It is now Februari 5th, 2002 and I just installed 0.9.8. Apart from the
atrocious slowdown in the mozilla website (the others fly at normal speed), I
have just crashed very consistently, at the same point in loading as I used to
crash before 0.9.7 came out :(. This is three out of three attempts to load
www.iht.com, not as infrequent and erratic as it was in 0.9.8.

I filed my talkbacks:
TB2438964M
TB2477829H
TB2333812H

Good hunting, gentlemen, and godspeed. This particular bug deserves to be
squished once and for all.

Comment 94

[Ron Thigpen]

Also seeing return of crash bug on load of www.iht.com

Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.8) Gecko/20020204
TB2544791K
TB2544695W

Comment 95

[Jay Patel [:jay]]

I dug up the incidents mentioned in the comments above...here are a couple:

 Incident ID 2333812   
Stack Signature  0x000006cc f0b5a1ea
Trigger Time 2002-01-31 05:43:50
Email Address [e-mail]
URL visited www.iht.com
User Comments Same bloody crash as usual. Please fix it. It is now erratic, but
still happens to me more than any other crash. MTBF is seriously impaired here...
Build ID 2001122109
Product ID MozillaBranch
Platform
Operating System Win32
Module
Trigger Reason Access violation
Stack Trace
0x000006cc
nsAString::do_AssignFromReadable
[d:\builds\seamonkey\mozilla\string\src\nsAString.cpp, line 290]
nsAString::AssignFromReadable
[d:\builds\seamonkey\mozilla\string\src\nsAString.cpp, line 239]
nsFont::operator= [d:\builds\seamonkey\mozilla\gfx\src\nsFont.cpp, line 104]
nsFontMetricsWin::Init
[d:\builds\seamonkey\mozilla\gfx\src\windows\nsFontMetricsWin.cpp, line 452]
nsFontCache::GetMetricsFor
[d:\builds\seamonkey\mozilla\gfx\src\nsDeviceContext.cpp, line 676]
DeviceContextImpl::GetMetricsFor
[d:\builds\seamonkey\mozilla\gfx\src\nsDeviceContext.cpp, line 308]
nsTextFrame::TextStyle::TextStyle
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsTextFrame.cpp, line 549]
nsTextFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsTextFrame.cpp, line 5047]
nsLineLayout::ReflowFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsLineLayout.cpp, line 1087]
nsBlockFrame::ReflowInlineFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3688]
nsBlockFrame::DoReflowInlineFrames
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3569]
nsBlockFrame::DoReflowInlineFramesAuto
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3494]
nsBlockFrame::ReflowInlineFrames
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3439]
nsBlockFrame::ReflowLine
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2475]
nsBlockFrame::ReflowDirtyLines
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2159]
nsBlockFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 826]
nsBlockReflowContext::DoReflowBlock
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line
581]
nsBlockReflowContext::ReflowBlock
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line
359]
nsBlockFrame::ReflowBlockFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3183]
nsBlockFrame::ReflowLine
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2386]
nsBlockFrame::ReflowDirtyLines
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2159]
nsBlockFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 826]
nsBlockReflowContext::DoReflowBlock
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line
581]
nsBlockReflowContext::ReflowBlock
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line
359]
nsBlockFrame::ReflowBlockFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3183]
nsBlockFrame::ReflowLine
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2386]
nsBlockFrame::ReflowDirtyLines
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2159]
nsBlockFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 826]
nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 766]
nsTableCellFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableCellFrame.cpp, line 943]
nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 766]
nsTableRowFrame::IR_TargetIsChild
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowFrame.cpp, line 1263]
nsTableRowFrame::IncrementalReflow
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowFrame.cpp, line 1158]
nsTableRowFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowFrame.cpp, line 1433]
nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 766]
nsTableRowGroupFrame::IR_TargetIsChild
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowGroupFrame.cpp,
line 1559]
nsTableRowGroupFrame::IncrementalReflow
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowGroupFrame.cpp,
line 1236]
nsTableRowGroupFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowGroupFrame.cpp,
line 1146]
nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 766]
nsTableFrame::IR_TargetIsChild
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableFrame.cpp, line 2861]
nsTableFrame::IncrementalReflow
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableFrame.cpp, line 2700]
nsTableFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableFrame.cpp, line 1955]
nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 766]
nsTableOuterFrame::OuterReflowChild
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableOuterFrame.cpp, line 983]
nsTableOuterFrame::IR_InnerTableReflow
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableOuterFrame.cpp, line 1300]
nsTableOuterFrame::IR_TargetIsInnerTableFrame
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableOuterFrame.cpp, line 1089]
nsTableOuterFrame::IR_TargetIsChild
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableOuterFrame.cpp, line 1079]
nsTableOuterFrame::IncrementalReflow
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableOuterFrame.cpp, line 1042]
nsTableOuterFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableOuterFrame.cpp, line 1535]
nsBlockReflowContext::DoReflowBlock
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line
581]
nsBlockReflowContext::ReflowBlock
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line
359]
nsBlockFrame::ReflowBlockFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3183]
nsBlockFrame::ReflowLine
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2386]
nsBlockFrame::ReflowDirtyLines
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2159]
nsBlockFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 826]
nsBlockReflowContext::DoReflowBlock
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line
581]
nsBlockReflowContext::ReflowBlock
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line
359]
nsBlockFrame::ReflowBlockFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3183]
nsBlockFrame::ReflowLine
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2386]
nsBlockFrame::ReflowDirtyLines
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2159]
nsBlockFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 826]
nsBlockReflowContext::DoReflowBlock
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line
581]
nsBlockReflowContext::ReflowBlock
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line
359] 

And....

 Incident ID 2544791   
Stack Signature  0x0000050a 86304d9c
Trigger Time 2002-02-05 12:18:37
Email Address
URL visited www.iht.com
User Comments Loading www.iht.com homepage immediately crashes Moz.
Build ID 2002020409
Product ID MozillaBranch
Platform
Operating System Win32
Module
Trigger Reason Access violation
Stack Trace
0x0000050a
nsAString::do_AssignFromReadable
[d:\builds\seamonkey\mozilla\string\src\nsAString.cpp, line 290]
nsAString::AssignFromReadable
[d:\builds\seamonkey\mozilla\string\src\nsAString.cpp, line 758]
nsFont::operator= [d:\builds\seamonkey\mozilla\gfx\src\nsFont.cpp, line 104]
nsFontMetricsWin::Init
[d:\builds\seamonkey\mozilla\gfx\src\windows\nsFontMetricsWin.cpp, line 469]
nsFontCache::GetMetricsFor
[d:\builds\seamonkey\mozilla\gfx\src\nsDeviceContext.cpp, line 671]
DeviceContextImpl::GetMetricsFor
[d:\builds\seamonkey\mozilla\gfx\src\nsDeviceContext.cpp, line 303]
nsTextFrame::TextStyle::TextStyle
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsTextFrame.cpp, line 554]
nsTextFrame::Paint
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsTextFrame.cpp, line 1429]
nsContainerFrame::PaintChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 254]
nsBlockFrame::PaintChildren
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 5515]
nsBlockFrame::Paint
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 5387]
nsContainerFrame::PaintChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 254]
nsBlockFrame::PaintChildren
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 5515]
nsBlockFrame::Paint
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 5387]
nsContainerFrame::PaintChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 254]
nsContainerFrame::PaintChildren
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 197]
nsTableCellFrame::Paint
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableCellFrame.cpp, line 481]
nsTableRowFrame::PaintChildren
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowFrame.cpp, line 672]
nsTableRowFrame::Paint
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowFrame.cpp, line 614]
nsTableRowGroupFrame::PaintChildren
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowGroupFrame.cpp,
line 327]
nsTableRowGroupFrame::Paint
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowGroupFrame.cpp,
line 270]
nsContainerFrame::PaintChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 254]
nsContainerFrame::PaintChildren
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 197]
nsTableFrame::Paint
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableFrame.cpp, line 1511]
nsContainerFrame::PaintChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 254]
nsTableOuterFrame::Paint
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableOuterFrame.cpp, line 370]
nsContainerFrame::PaintChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 254]
nsBlockFrame::PaintChildren
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 5515]
nsBlockFrame::Paint
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 5387]
nsContainerFrame::PaintChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 254]
nsContainerFrame::PaintChildren
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 197]
nsTableCellFrame::Paint
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableCellFrame.cpp, line 481]
nsTableRowFrame::PaintChildren
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowFrame.cpp, line 672]
nsTableRowFrame::Paint
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowFrame.cpp, line 614]
nsTableRowGroupFrame::PaintChildren
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowGroupFrame.cpp,
line 327]
nsTableRowGroupFrame::Paint
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowGroupFrame.cpp,
line 270]
nsContainerFrame::PaintChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 254]
nsContainerFrame::PaintChildren
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 197]
nsTableFrame::Paint
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableFrame.cpp, line 1511]
nsContainerFrame::PaintChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 254]
nsTableOuterFrame::Paint
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableOuterFrame.cpp, line 370]
nsContainerFrame::PaintChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 254]
nsBlockFrame::PaintChildren
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 5515]
nsBlockFrame::Paint
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 5387]
nsContainerFrame::PaintChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 254]
nsBlockFrame::PaintChildren
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 5515]
nsBlockFrame::Paint
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 5387]
nsContainerFrame::PaintChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 254]
nsBlockFrame::PaintChildren
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 5515]
nsBlockFrame::Paint
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 5387]
nsContainerFrame::PaintChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 254]
nsContainerFrame::PaintChildren
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 197]
nsHTMLContainerFrame::Paint
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLContainerFrame.cpp, line
136]
CanvasFrame::Paint
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLFrame.cpp, line 390]
PresShell::Paint
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5713]
nsView::Paint [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 272]
nsViewManager::RenderDisplayListElement
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1240]
nsViewManager::RenderViews
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1164]
nsViewManager::Refresh [d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp,
line 703]
nsViewManager::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1762]
HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 83]
nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 854]
nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 876] 


Is looks like nsAString::do_AssignFromReadable is still where the crash is, but
the crashes are being reported under different stack signatures by Talkback. 
Adding testcase keyword, since it seems pretty clear that we are crashing at
www.iht.com.

Comment 96

[Oscar van Vliet]

Please note that my stack trace listed below is from before I installed 0.9.8. I
think I haven't sent in the first crash, believing it to be erratic like the
other one I had sent in a week earlier. Sorry for not being specific. Also, I am
still running NT4 SP6 on a Celeron 300A with 128 MB RAM.
BTW, www.mozilla.org is back up to speed for me :).

How about adding 0.9.9 keyword :)? <wink wink> Again, thanks for the hot attention!

Comment 97

[Shiva Thirumazhusai]

nominating for nsbeta1. 

Comment 98

[Matthias Versen [:Matti]]

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

Comment 99

[René]

Here's a stack from Solaris 2.8 build, ID: 2002020516 (www.iht.com)

#0  0x7f9e33c4 in CopyChars1To2 () from /home/la/bin/mozilla/libxpcom.so
#1  0x7f9e3e3c in nsStr::StrAppend () from /home/la/bin/mozilla/libxpcom.so
#2  0x7f9e3d74 in nsStr::StrAssign () from /home/la/bin/mozilla/libxpcom.so
#3  0x7f9e8114 in nsString::nsString () from /home/la/bin/mozilla/libxpcom.so
#4  0x7fb55718 in nsFont::nsFont () from /home/la/bin/mozilla/libgkgfx.so
#5  0x7e185414 in nsFontMetricsGTK::Init () from
/home/la/bin/mozilla/components/libgfx_gtk.so
#6  0x7fb552b0 in nsFontCache::GetMetricsFor () from
/home/la/bin/mozilla/libgkgfx.so
#7  0x7fb54588 in DeviceContextImpl::GetMetricsFor () from
/home/la/bin/mozilla/libgkgfx.so
#8  0x7d641f88 in nsTextFrame::Paint () from
/home/la/bin/mozilla/components/libgklayout.so
#9  0x7d5f8374 in nsContainerFrame::PaintChild () from
/home/la/bin/mozilla/components/libgklayout.so
#10 0x7d5f145c in nsBlockFrame::PaintChildren () from
/home/la/bin/mozilla/components/libgklayout.so
#11 0x7d5f1254 in nsBlockFrame::Paint () from
/home/la/bin/mozilla/components/libgklayout.so
#12 0x7d6396d0 in PresShell::Paint () from
/home/la/bin/mozilla/components/libgklayout.so
#13 0x7d869198 in nsView::Paint () from /home/la/bin/mozilla/components/libgkview.so
#14 0x7d873068 in nsViewManager::RenderDisplayListElement () from
/home/la/bin/mozilla/components/libgkview.so
#15 0x7d872e24 in nsViewManager::RenderViews () from
/home/la/bin/mozilla/components/libgkview.so
#16 0x7d871ab0 in nsViewManager::Refresh () from
/home/la/bin/mozilla/components/libgkview.so
#17 0x7d874468 in nsViewManager::DispatchEvent () from
/home/la/bin/mozilla/components/libgkview.so
#18 0x7d868c08 in _start () from /home/la/bin/mozilla/components/libgkview.so
#19 0x7e6bc0d4 in nsWidget::DispatchEvent () from
/home/la/bin/mozilla/components/libwidget_gtk.so
#20 0x7e6bbfe4 in nsWidget::DispatchWindowEvent () from
/home/la/bin/mozilla/components/libwidget_gtk.so
#21 0x7e6bf520 in nsWindow::DoPaint () from
/home/la/bin/mozilla/components/libwidget_gtk.so
#22 0x7e6bf6ec in nsWindow::Update () from
/home/la/bin/mozilla/components/libwidget_gtk.so
#23 0x7e6bf3a0 in nsWindow::UpdateIdle () from
/home/la/bin/mozilla/components/libwidget_gtk.so
#24 0x7f6292ec in g_idle_dispatch (source_data=0x7e6bf324,
dispatch_time=0xffbee028, user_data=0x0) at gmain.c:1367
#25 0x7f627cfc in g_main_dispatch (dispatch_time=0xffbee028) at gmain.c:656
#26 0x7f628598 in g_main_iterate (block=2137316692, dispatch=1) at gmain.c:877
#27 0x7f6287ac in g_main_run (loop=0x20f9c8) at gmain.c:935
#28 0x7f749ca0 in gtk_main () at gtkmain.c:524
#29 0x7e6ae7f8 in nsAppShell::Run () from
/home/la/bin/mozilla/components/libwidget_gtk.so
#30 0x7f03bae0 in nsAppShellService::Run () from
/home/la/bin/mozilla/components/libnsappshell.so
#31 0x180a8 in DoCommandLines ()
#32 0x18b38 in main ()

Comment 100

[Matthias Versen [:Matti]]

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

Comment 101

[R.K.Aa.]

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

Comment 102

[Oscar van Vliet]

Is a fix for this bug still going to go in for 0.9.9? I've been keeping an eye
out and I haven't seen this one in Asa's daily bug lists.

BTW, this bug should have most-frequent keyword added, there are 25 duplicates
on record.

Comment 103

[Mark Slater]

Still crashing with 2002022308.

Talkback Incident ID is TB3297169Z.

Comment 104

[Andrew Schultz]

Attachment: testcase from bug 127120

This testcase crashes immeadiately every time.	The javascript changing the
style height nukes style (specifically font) data not associated with the <div>
or <textarea> tags.  Mozilla then attempts to use that font data when it
repaints the screen, causing an immediate crash (stacktrace in bug 127120).

If you want to catch it deleting the font from the cache, set a breakpoint for
nsFont::~nsFont and/or nsDOMCSSDeclaration::SetHeight.	It is the first font to
be deleted, and SetHeight is only called once.

Comment 105

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

Attachment: fix

This typo was a regression from the rework of nsRuleNode children storage in
the fix to bug 104336.

Comment 106

[Andrew Schultz]

patch fixes testcase and URL in bug 127120

Comment 107

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

The reason this was crashing was that we were clearing too much, because it tell
every rule node to clear the data for *its* rule.  Clearing too much caused a
problem because this left the style contexts with dangling pointers to the data
that was cleared but shouldn't have been, since the clearStyleData called on the
root context from the second part of StyleSetImpl::ClearStyleData didn't clear
too much to correspond with the rule node clearing out everything.

Comment 108

[Brendan Eich [:brendan]]

hyatt's away till Tuesday.  Who can r= with authority?  I can sr=.

/be

Comment 109

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

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

Comment 110

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

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

Comment 111

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 72166 [details] [diff] [review]
fix

r=bzbarsky

Comment 112

[Matthias Versen [:Matti]]

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

Comment 113

[Brendan Eich [:brendan]]

Comment on attachment 72166 [details] [diff] [review]
fix

sr=[e-mail]

/be

Comment 114

[Mike Shaver (:shaver emeritus)]

Comment on attachment 72166 [details] [diff] [review]
fix

a=shaver for 0.9.9 and 1.0.

Comment 115

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

Fix checked in:
 * to trunk, 2002-03-02 16:00:16 PST, and
 * to MOZILLA_0_9_9_BRANCH, 2002-03-02 16:02:00 PST.

Comment 116

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

If only bugzilla could read my mind...

Comment 117

[Henrik Gemal]

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

Comment 118

[rbs]

Good job in hunting the regression, dbaron. Just noted that, actually, you
explicitly quoted this code fragment in your review in bug 104336 comment #105,
but somehow it didn't cross your mind then.

Comment 119

[rbs]

s/bug 104336 comment #105/bug 104336 comment #33/

Comment 120

[greer]

Attachment: Stacks from M099 at nsAString::do_AssignFromReadable

dbaron, we're seeing stacks in the M099 data (post-fix checkin) that resemble
those in comments 82-86. Would it be better to address those crashes in a
separate bug or just reopen this one?

Comment 121

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

The stacks in comment 120 are very different from those in comment 84 -- they
show problems in a XUL document rather than an HTML document, and they're
related to theme changing.  Could you file a new bug?  (Probably Style System
component.)

Comment 122

[rbs]

-> looks like the existing bug 121638

Comment 123

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

bug 130696 was filed.

Comment 124

[Amarendra Hanumanula]

 Changing the QA contact to madhur

Comment 125

[Madhur Bhatia]

verified fixed in win2000 - buiild: 2002-03-07-trunk and 2002-04-10-06trunk 
build

Comment 126

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

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

Comment 127

[Jesse Ruderman]

Crashtest added as part of http://hg.mozilla.org/mozilla-central/rev/54417ebbaea2