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

VERIFIED FIXED in mozilla0.9.9

Status

()

Core
CSS Parsing and Computation
P1
critical
VERIFIED FIXED
16 years ago
9 years ago

People

(Reporter: Mikael Nilsson, Assigned: dbaron)

Tracking

(5 keywords)

Trunk
mozilla0.9.9
crash, regression, testcase, top100, topcrash
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(crash signature, URL)

Attachments

(11 attachments, 4 obsolete attachments)

3.50 KB, text/plain
Details
640 bytes, text/html
Details
1.19 KB, patch
shaver
: review+
David Hyatt
: superreview+
Details | Diff | Splinter Review
3.38 KB, text/plain
Details
1.90 KB, text/plain
Details
263.69 KB, application/octet-stream
Details
20.90 KB, text/plain
Details
8.22 KB, text/plain
Details
288 bytes, text/html
Details
fix
1.20 KB, patch
brendan
: superreview+
shaver
: approval+
Details | Diff | Splinter Review
7.56 KB, text/plain
Details
(Reporter)

Description

16 years ago
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

16 years ago
TB36901281E

Comment 2

16 years ago
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]

Updated

16 years ago
Keywords: crash

Comment 3

16 years ago
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

Comment 4

16 years ago
*** Bug 108994 has been marked as a duplicate of this bug. ***
Keywords: mozilla0.9.7
OS: Linux → All
Hardware: PC → All

Comment 5

16 years ago
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)

Comment 6

16 years ago
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).
(Assignee)

Comment 7

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

Updated

16 years ago
Keywords: top100

Comment 8

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

Comment 9

16 years ago
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?
(Assignee)

Comment 10

16 years ago
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

16 years ago
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

16 years ago
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
Component: String → Style System
Keywords: regression
QA Contact: scc → ian

Comment 13

16 years ago
Created attachment 57433 [details]
FYI - patch used for inspection - includes explanatory comments
(Reporter)

Comment 14

16 years ago
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

16 years ago
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 ?

(Reporter)

Comment 16

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

Blocks: 104864
(Assignee)

Comment 17

16 years ago
hyatt, any thoughts?

Comment 18

16 years ago
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()
(Assignee)

Updated

16 years ago
Keywords: topcrash
(Assignee)

Comment 19

16 years ago
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

16 years ago
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
(Assignee)

Comment 21

16 years ago
Created attachment 59126 [details] [diff] [review]
patch that ought to fix the crash (still need to test where I can reproduce)
(Assignee)

Comment 22

16 years ago
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.
(Assignee)

Comment 23

16 years ago
Created attachment 59127 [details] [diff] [review]
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.
Attachment #59126 - Attachment is obsolete: true
(Assignee)

Comment 24

16 years ago
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.)
(Assignee)

Comment 25

16 years ago
Created attachment 59128 [details] [diff] [review]
more-cleaned-up version of patch which I think is correct but unrelated to this bug
Attachment #59127 - Attachment is obsolete: true
(Assignee)

Comment 26

16 years ago
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

16 years ago
+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?
(Assignee)

Comment 28

16 years ago
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

16 years ago
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.
(Assignee)

Comment 30

16 years ago
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
(Assignee)

Comment 31

16 years ago
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

16 years ago
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

16 years ago
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

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

Comment 35

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

Comment 36

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

TB38567098Z
TB38567053M
TB38567005M

--rt
(Assignee)

Comment 37

16 years ago
*** Bug 112451 has been marked as a duplicate of this bug. ***
*** Bug 112454 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 39

16 years ago
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

16 years ago
I'm building on sheep but it very slow and I may run out of time today.
(Assignee)

Comment 41

16 years ago
stephend sent me a purify log, but it wasn't very useful, since it just showed a
null pointer dereference
(Assignee)

Comment 42

16 years ago
Created attachment 59623 [details]
simplified testcase
(Assignee)

Comment 43

16 years ago
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

16 years ago
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

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

Comment 46

16 years ago
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.

Comment 48

16 years ago
The testcase gives me a completely different stack trace than the original page.
*** Bug 112431 has been marked as a duplicate of this bug. ***

Comment 50

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

Comment 51

16 years ago
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]
(Assignee)

Comment 52

16 years ago
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

16 years ago
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
(Assignee)

Comment 54

16 years ago
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...
(Assignee)

Comment 55

16 years ago
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;
 }
(Assignee)

Comment 56

16 years ago
The assertion line should really be:

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

Comment 57

16 years ago
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.
(Assignee)

Comment 59

16 years ago
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.
(Assignee)

Comment 60

16 years ago
Created attachment 60747 [details] [diff] [review]
patch fixing this bug
(Assignee)

Comment 61

16 years ago
Created attachment 60748 [details] [diff] [review]
patch preventing frame access after deletion (and some other cleanup)

Comment 62

16 years ago
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

16 years ago
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 64

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

sr=hyatt
Attachment #60747 - Flags: superreview+

Updated

16 years ago
Blocks: 113492
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla0.9.7
(Assignee)

Comment 65

16 years ago
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
Comment on attachment 60747 [details] [diff] [review]
patch fixing this bug

r=shaver
Attachment #60747 - Flags: review+
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.
(Assignee)

Comment 68

16 years ago
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
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 69

16 years ago
just crashed with build 2001121003 on win2k!
TB324891G

Comment 70

16 years ago
Created attachment 61252 [details]
Stack from Talkback incident 324891

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

Comment 71

16 years ago
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

16 years ago
*** Bug 116205 has been marked as a duplicate of this bug. ***
*** Bug 116274 has been marked as a duplicate of this bug. ***

Comment 74

16 years ago
Created attachment 62581 [details]
purify info 2001-12-20 solaris build

Comment 75

16 years ago
Created attachment 62583 [details]
purify log file (*.pv)

this is the full purify log

Comment 76

16 years ago
oops, I forgot to say:

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

Comment 77

16 years ago
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

16 years ago
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)
(Assignee)

Comment 79

16 years ago
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

Comment 80

16 years ago
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

16 years ago
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

16 years ago
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

16 years ago
Also crashing with build 2002012203 on winxp.
TB1972641K

Comment 84

16 years ago
Created attachment 66006 [details]
Stacks for incidents in Comments 82 & 83

The above stacks look like they belong to bug 106341.
(Assignee)

Comment 85

16 years ago
*** Bug 106341 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 86

16 years ago
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.
(Assignee)

Comment 87

16 years ago
*** Bug 117198 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 88

16 years ago
*** Bug 107367 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

16 years ago
Target Milestone: Future → mozilla0.9.9
(Assignee)

Comment 89

16 years ago
Created attachment 66218 [details]
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

16 years ago
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

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

Comment 92

16 years ago
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]

Comment 93

16 years ago
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

16 years ago
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

16 years ago
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

Comment 96

16 years ago
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

16 years ago
nominating for nsbeta1. 
Keywords: nsbeta1
*** Bug 126508 has been marked as a duplicate of this bug. ***

Comment 99

16 years ago
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. ***
Blocks: 88684

Comment 101

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

Comment 102

16 years ago
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

16 years ago
Still crashing with 2002022308.

Talkback Incident ID is TB3297169Z.

Comment 104

16 years ago
Created attachment 72013 [details]
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.
(Assignee)

Comment 105

16 years ago
Created attachment 72166 [details] [diff] [review]
fix

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

Comment 106

16 years ago
patch fixes testcase and URL in bug 127120
(Assignee)

Comment 107

16 years ago
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
(Assignee)

Comment 109

16 years ago
*** Bug 125480 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 110

16 years ago
*** 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. ***
Comment on attachment 72166 [details] [diff] [review]
fix

sr=brendan@mozilla.org

/be
Attachment #72166 - Flags: superreview+
Comment on attachment 72166 [details] [diff] [review]
fix

a=shaver for 0.9.9 and 1.0.
Attachment #72166 - Flags: approval+
(Assignee)

Comment 115

16 years ago
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.
(Assignee)

Comment 116

16 years ago
If only bugzilla could read my mind...
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Comment 117

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

Comment 118

16 years ago
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

16 years ago
s/bug 104336 comment #105/bug 104336 comment #33/

Comment 120

16 years ago
Created attachment 73929 [details]
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?
(Assignee)

Comment 121

16 years ago
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

16 years ago
-> looks like the existing bug 121638
(Assignee)

Comment 123

16 years ago
bug 130696 was filed.
 Changing the QA contact to madhur
QA Contact: amar → madhur

Comment 125

16 years ago
verified fixed in win2000 - buiild: 2002-03-07-trunk and 2002-04-10-06trunk 
build
Status: RESOLVED → VERIFIED
(Assignee)

Comment 126

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

Comment 127

9 years ago
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.