Closed Bug 105619 Opened 23 years ago Closed 22 years ago

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

Categories

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

Product:
Core
Component:
CSS Parsing and Computation
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.9

People

(Reporter: mikael, Assigned: dbaron)

References

(
URL
)

Details

(5 keywords)

Crash Data

Attachments

(11 files, 4 obsolete files)

FYI - patch used for inspection - includes explanatory comments
3.50 KB, text/plain
Details
simplified testcase
640 bytes, text/html
Details
patch fixing this bug
1.19 KB, patch
shaver
: review+
hyatt
: superreview+
Details | Diff | Splinter Review
Stack from Talkback incident 324891
3.38 KB, text/plain
Details
purify info 2001-12-20 solaris build
1.90 KB, text/plain
Details
purify log file (*.pv)
263.69 KB, application/octet-stream
Details
Stacks for incidents in Comments 82 & 83
20.90 KB, text/plain
Details
debugging notes for http://www.iht.com/
8.22 KB, text/plain
Details
testcase from bug 127120
288 bytes, text/html
Details
fix
1.20 KB, patch
bzbarsky
: review+
brendan
: superreview+
shaver
: approval+
Details | Diff | Splinter Review
Stacks from M099 at nsAString::do_AssignFromReadable
7.56 KB, text/plain
Details 
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.
TB36901281E
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
......
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Javascript menus crash mozilla 0.9.5 & CVS → Javascript menus crash mozilla 0.9.5 & CVS [@ CopyChars1To2]
Keywords: crash
moving to strings, probably belongs to fonts (which doesn't exist as a
component, layout?)
Assignee: asa → scc
Component: Browser-General → String
QA Contact: doronr → scc
*** Bug 108994 has been marked as a duplicate of this bug. ***
Keywords: mozilla0.9.7
OS: Linux → All
Hardware: PC → All
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 <scc@netscape.com> 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)

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).
Anyway, that stack makes it look like it's crashing in the string's constructor,
not AssignWithConversion.  Maybe some memory is corrupt?
Keywords: top100
*** Bug 108240 has been marked as a duplicate of this bug. ***
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?
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.
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 :)
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.
Assignee: scc → dbaron
URL: http://ulldb.ull.uu.se/matdid/pub/bsc... → http://www.iht.com/frontpage.htm
Component: String → Style System
Keywords: regression
QA Contact: scc → ian
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
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 ?


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


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()
That's the stack you get when someone tries to append (to?) a bogus string.  It
shouldn't all be lumped into one bug.
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.
QA Contact: ian → amar
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.
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.
Attachment #59126 - Attachment is obsolete: true
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.)
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.
+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?
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?
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 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.
Attachment #59128 - Attachment is obsolete: true
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...
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.
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.
*** Bug 111061 has been marked as a duplicate of this bug. ***
*** Bug 112311 has been marked as a duplicate of this bug. ***
Talkback IDs from Bug 112311, which is currently marked as a duplicate of this
(105619).

TB38567098Z
TB38567053M
TB38567005M

--rt
*** Bug 112451 has been marked as a duplicate of this bug. ***
*** Bug 112454 has been marked as a duplicate of this bug. ***
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).
I'm building on sheep but it very slow and I may run out of time today.
stephend sent me a purify log, but it wasn't very useful, since it just showed a
null pointer dereference
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.
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.
Nope, I still crash with the patch from 97874. Oh, vell.
Might this be a regression of bug 91479?  That bug has a similar stack to the
ones reported here.
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.
The testcase gives me a completely different stack trace than the original page.
*** Bug 112431 has been marked as a duplicate of this bug. ***
*** Bug 112819 has been marked as a duplicate of this bug. ***
Adding [@ FrameManager::ReResolveStyleContext] to summary since bug 111061 was
marked a dup and that crash is a topcrasher on recent MozillaTrunk builds as well.
Summary: Javascript menus crash mozilla 0.9.5 & CVS [@ CopyChars1To2] → Javascript menus crash mozilla 0.9.5 & CVS [@ CopyChars1To2][@ FrameManager::ReResolveStyleContext]
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.
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
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...
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;
 }

The assertion line should really be:

+  NS_ASSERTION(!PL_DHASH_ENTRY_IS_BUSY(entry) || entry->frame != aFrame,
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.
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.
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.
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 :).
ovvldc@netscape.net:
> 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 on attachment 60747 [details] [diff] [review]
patch fixing this bug

sr=hyatt
Attachment #60747 - Flags: superreview+
Blocks: 113492
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla0.9.7
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
Attachment #60748 - Attachment is obsolete: true
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.
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.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
just crashed with build 2001121003 on win2k!
TB324891G

Here is the talkback stack from comment #69 above. Doesn't look like the same
animal.
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.
*** Bug 116205 has been marked as a duplicate of this bug. ***
*** Bug 116274 has been marked as a duplicate of this bug. ***
Attached file purify log file (*.pv) — 
this is the full purify log
oops, I forgot to say:

 "it crashed" on the url http://www.iht.com/frontpage.htm
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.
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)
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?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla0.9.7 → Future
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

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 :(

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
Also crashing with build 2002012203 on winxp.
TB1972641K
The above stacks look like they belong to bug 106341.
*** Bug 106341 has been marked as a duplicate of this bug. ***
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.
*** Bug 117198 has been marked as a duplicate of this bug. ***
*** Bug 107367 has been marked as a duplicate of this bug. ***
Target Milestone: Future → mozilla0.9.9
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.
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?
*** Bug 122767 has been marked as a duplicate of this bug. ***
adding [@ nsAString::do_AssignFromReadable][@ nsAString::AssignFromReadable] to
summary for tracking...since bug 106341 was marked a dup.
Summary: Javascript menus crash mozilla 0.9.5 & CVS [@ CopyChars1To2][@ FrameManager::ReResolveStyleContext] → Javascript menus crash mozilla 0.9.5 & CVS [@ CopyChars1To2][@ FrameManager::ReResolveStyleContext] [@ nsAString::do_AssignFromReadable][@ nsAString::AssignFromReadable]
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.
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
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 ovvldc@netscape.net
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.
Keywords: testcase
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!

nominating for nsbeta1.
Keywords: nsbeta1
*** Bug 126508 has been marked as a duplicate of this bug. ***
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 ()
*** Bug 127106 has been marked as a duplicate of this bug. ***
*** Bug 127377 has been marked as a duplicate of this bug. ***
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.
Still crashing with 2002022308.

Talkback Incident ID is TB3297169Z.
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.
Attached patch fix — — Splinter Review 
This typo was a regression from the rework of nsRuleNode children storage in
the fix to bug 104336.
patch fixes testcase and URL in bug 127120
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.
No longer blocks: 122050
hyatt's away till Tuesday.  Who can r= with authority?  I can sr=.

/be
*** Bug 125480 has been marked as a duplicate of this bug. ***
*** Bug 127120 has been marked as a duplicate of this bug. ***
Comment on attachment 72166 [details] [diff] [review]
fix

r=bzbarsky
Attachment #72166 - Flags: review+
*** Bug 128605 has been marked as a duplicate of this bug. ***
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.
If only bugzilla could read my mind...
Status: REOPENED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
*** Bug 126131 has been marked as a duplicate of this bug. ***
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.
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?
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.)
-> looks like the existing bug 121638
 Changing the QA contact to madhur
QA Contact: amar → madhur
verified fixed in win2000 - buiild: 2002-03-07-trunk and 2002-04-10-06trunk 
build
Status: RESOLVED → VERIFIED
*** Bug 112696 has been marked as a duplicate of this bug. ***
Crashtest added as part of http://hg.mozilla.org/mozilla-central/rev/54417ebbaea2
Flags: in-testsuite+
Crash Signature: [@ CopyChars1To2] [@ FrameManager::ReResolveStyleContext] [@ nsAString::do_AssignFromReadable] [@ nsAString::AssignFromReadable]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: