132647 - Crash when save a document by changing the charset in Composer

Status: VERIFIED WORKSFORME

(Core :: Internationalization, defect)

Description

[Yuying Long]

Build: 03-20 trunk build / WinXP
       03-20 trunk build / Linux RH7.2
       03-21 trunk build / Mac 10.1.3

Steps:
1. Launch browser and load any web site, e.g. http://www.yahoo.com
2. File | Edit Page to bring it into Composer window.
3. File | Save As Charset, select a charset that different than the original
document, and save it.

Result:
Crash

Comment 1

[Yuying Long]

Attachment: Talkback ID 4314452

Comment 2

[Yuying Long]

Crash -> nsbeta1

And it's also a regression, I don't see it on 03-08 trunk build.

Comment 3

[Jay Patel [:jay]]

Moving comment from bug 132067 and cc'ing Brian:

------- Additional Comment #30 From Brian Nesse 2002-03-21 13:13 -------

Hmm, I wonder if it's only a coincidence that this is also going though the font
code that is also causing bug 132370 (Mac only). (i.e.
mozilla/gfx/src/mac/nsDeviceContextMac.cpp vs. mozilla\gfx\src\nsDeviceContext.cpp)

Comment 4

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

No, this seems like accessing corrupt style data.  Attinasi was working on a bug
that could be related -- bug 124333.

Comment 5

[nhottanscp]

nsbeta1+

Comment 6

[Roy Yokoyama]

The crash doesn't always occure.  I can consistantly get
a crash only when you visit www.yahoo.com and SaveAsCharset to
EUC-JP.  Other conditions don't crash.

Once I got a crash, the trace is different from the TalkBack.
(however, I was able to get the same TalkBack trace once. )
Here it is:
_NMSG_WRITE(int 255) line 221
_FF_MSGBANNER() line 169 + 10 bytes
_amsg_exit(int 25) line 324
_purecall() line 35 + 7 bytes
nsAString::Equals(const nsAString & {...}, const nsStringComparator & {...})
line 737 + 24 bytes
nsFont::Equals(const nsFont & {...}) line 96 + 141 bytes
nsFontCache::GetMetricsFor(nsFontCache * const 0x1069c118, const nsFont & {...},
nsIAtom * 0x0460edc8, nsIFontMetrics * & 0x00000000) line 645 + 12 bytes
DeviceContextImpl::GetMetricsFor(DeviceContextImpl * const 0x0fd9e760, const
nsFont & {...}, nsIAtom * 0x0460edc8, nsIFontMetrics * & 0x00000000) line 303
ComputeLineHeight(nsIRenderingContext * 0x10a3bf50, nsIStyleContext *
0x107b7cf0) line 2205 + 63 bytes
nsHTMLReflowState::CalcLineHeight(nsIPresContext * 0x10474028,
nsIRenderingContext * 0x10a3bf50, nsIFrame * 0x107b7c7c) line 2245 + 18 bytes
nsBlockReflowState::nsBlockReflowState(const nsHTMLReflowState & {...},
nsIPresContext * 0x10474028, nsBlockFrame * 0x107b7c7c, const
nsHTMLReflowMetrics & {...}, int 0) line 178 + 26 bytes
nsBlockFrame::Reflow(nsBlockFrame * const 0x107b7c7c, nsIPresContext *
0x10474028, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0) line 735
nsLineLayout::ReflowFrame(nsIFrame * 0x107b7c7c, nsIFrame * * 0x0011b7dc,
unsigned int & 0, nsHTMLReflowMetrics * 0x00000000, int & 0) line 1088 + 43 bytes
nsBlockFrame::ReflowInlineFrame(nsBlockReflowState & {...}, nsLineLayout &
{...}, nsLineList_iterator {...}, nsIFrame * 0x107b7c7c, unsigned char *
0x0011b024) line 3694 + 29 bytes
nsBlockFrame::DoReflowInlineFrames(nsBlockReflowState & {...}, nsLineLayout &
{...}, nsLineList_iterator {...}, int * 0x0011b30c, unsigned char * 0x0011b0b8,
int 0, int 0) line 3575 + 32 bytes
nsBlockFrame::DoReflowInlineFramesMalloc(nsBlockReflowState & {...},
nsLineList_iterator {...}, int * 0x0011b30c, unsigned char * 0x0011b0b8, int 0,
int 0) line 3479 + 40 bytes

In both cases, I see crashing in nsAString.
cc'ing alecf and jag for nsString 

Comment 7

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

This isn't a string problem.  See comment 4.

Comment 8

[Yuying Long]

> I can consistantly get a crash only when you visit www.yahoo.com and 
> SaveAsCharset to EUC-JP.  Other conditions don't crash.

It is true that on latast trunk build, I don't see the crash for each time, but
still quite offen for me.  E.g. 03-26 trunk build on Mac 10.1.3, when tried to
save page http://home.netscape.com/ja to iso-2022-jp, yahoo.com to IBM-850...etc.

Comment 9

[Roy Yokoyama]

124333 is nsbeta1-'ed.   

Comment 10

[Roy Yokoyama]

shanjian: since we own the font module, do we know what kind of changes   
          in Font Style might have caused this problem?  (Comment #4)
 

Comment 11

[Frank Tang]

 Impact Platform: ALL
Impact language users: ALL 560M 100%
Probability of hitting the problem: MID, save file in composer with different
charset is normal action
Severity if hit the problem in the worst case: crash
Way of recover after hit the problem: none
Risk of the fix: unknown
Potential benefit of fix this problem: other problem that caused by trashed
styledata

Comment 12

[Frank Tang]

this looks like a adt1 bug

Comment 13

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

I tried to reproduce this bug and was unable to.

Comment 14

[Yuying Long]

Hmm, now it works for me with 04-02 trunk build.

Comment 15

[Roy Yokoyama]

good. can we close it?

Comment 16

[Roy Yokoyama]

This might have fixed by other bug.
Marking WFM. Please reopen if disagree.

Comment 17

[Yuying Long]

Verified it's works for me on 04-04 trunk build.