195460 - Mozilla crashes when sending out a mail with a Ja img file inserted

Status: VERIFIED FIXED

(MailNews Core :: Internationalization, defect)

Description

[ji]

Build: 02/21 trunk

Steps to reproduce:
1. Open a mail compose window
2. Enter some Ja chars in the subject and mail body
3. Select Insert | Image..
4. From file dialog, select a img file with Ja filename
5. Change the mail encoding to ISO-2022-JP and click on Send, 
Mozilla crashes.

NS7.02 Ja doesn't crash, but the image filename is changed to ascii filename
after received.

Comment 1

[ji]

Incident ID 17605966
Stack Signature  	HankakuToZenkaku ada99f09
Email Address 	[e-mail]
Product ID 	MozillaTrunk
Build ID 	2003022105
Trigger Time 	2003-02-28 13:14:59
Platform 	Win32
Operating System 	Windows NT 5.1 build 2600
Module 	i18n.dll
URL visited 	
User Comments 	
Trigger Reason 	Access violation
Source File Name 
c:/builds/seamonkey/mozilla/intl/unicharutil/src/nsHankakuToZenkaku.cpp
Trigger Line No. 	128
Stack Trace 	
HankakuToZenkaku
[c:/builds/seamonkey/mozilla/intl/unicharutil/src/nsHankakuToZenkaku.cpp, line 128]
nsHankakuToZenkaku::Change
[c:/builds/seamonkey/mozilla/intl/unicharutil/src/nsHankakuToZenkaku.cpp, line 159]
generate_encodedwords
[c:/builds/seamonkey/mozilla/mailnews/mime/src/comi18n.cpp, line 347]
apply_rfc2047_encoding
[c:/builds/seamonkey/mozilla/mailnews/mime/src/comi18n.cpp, line 805]
MIME_EncodeMimePartIIStr
[c:/builds/seamonkey/mozilla/mailnews/mime/src/comi18n.cpp, line 1165]
nsMimeConverter::EncodeMimePartIIStr_UTF8
[c:/builds/seamonkey/mozilla/mailnews/mime/src/nsMimeConverter.cpp, line 158]
nsMsgI18NEncodeMimePartIIStr
[c:/builds/seamonkey/mozilla/mailnews/base/util/nsMsgI18N.cpp, line 402]
mime_generate_attachment_headers
[c:/builds/seamonkey/mozilla/mailnews/compose/src/nsMsgCompUtils.cpp, line 818]
nsMsgComposeAndSend::PreProcessPart
[c:/builds/seamonkey/mozilla/mailnews/compose/src/nsMsgSend.cpp, line 1307]
nsMsgComposeAndSend::GatherMimeAttachments
[c:/builds/seamonkey/mozilla/mailnews/compose/src/nsMsgSend.cpp, line 1153]
nsMsgAttachmentHandler::UrlExit
[c:/builds/seamonkey/mozilla/mailnews/compose/src/nsMsgAttachmentHandler.cpp,
line 1222]
FetcherURLDoneCallback
[c:/builds/seamonkey/mozilla/mailnews/compose/src/nsMsgAttachmentHandler.cpp,
line 482]
nsURLFetcher::OnStopRequest
[c:/builds/seamonkey/mozilla/mailnews/compose/src/nsURLFetcher.cpp, line 323]
nsDocumentOpenInfo::OnStopRequest
[c:/builds/seamonkey/mozilla/uriloader/base/nsURILoader.cpp, line 256]
nsFileChannel::OnStopRequest
[c:/builds/seamonkey/mozilla/netwerk/protocol/file/src/nsFileChannel.cpp, line 564]
nsCOMPtr_base::assign_with_AddRef
[c:/builds/seamonkey/mozilla/xpcom/glue/nsCOMPtr.cpp, line 70]
nsInputStreamPump::OnStateStop
[c:/builds/seamonkey/mozilla/netwerk/base/src/nsInputStreamPump.cpp, line 471]
nsInputStreamPump::OnInputStreamReady
[c:/builds/seamonkey/mozilla/netwerk/base/src/nsInputStreamPump.cpp, line 325] 

Comment 2

[ji]

From callstack, it looks like it crashes at HankakuToZenkaku, but I don't have
Hankaku katakana in the mail.

Comment 3

[nhottanscp]

The hankaku -> zenkaku conversion is always done for ISO-2022-JP messages.
I don't think the function changed recently, so I assume something garbage data
was passed in. Did this start from 2/21/2003?

Comment 4

[ji]

It also crashes using 1/29 trunk build.

Comment 5

[ji]

And crashes on 1/16 trunk build too. No more old trunk builds on my machine.

Comment 6

[Samir Gehani]

i18n triage team: nsbeta1+/adt1

Comment 7

[marina]

could be a dup of 196103 and 196256?

Comment 8

[nhottanscp]

Was this tesed on JA locale? Is this specific to image attachment or it can be
any attachment?

Comment 9

[ji]

Yes, this was tested in Ja locale. The function is for inserting an image, so 
only tested with an image file.

Comment 10

[nhottanscp]

Does it also crash when the image file is attached by "File -> Attach File..."?

Comment 11

[ji]

No, it doesn't crash in that case.

Comment 12

[marina]

Xianglan, does it crash in current builds? Thanks.

Comment 13

[ji]

yes, it still crashes on 2003051604-trunk build.

Comment 14

[Frank Tang]

Attachment: patch fix crash

Comment 15

[Frank Tang]

the crash happen in line 123 or 125 when the aLen is 0. The caller first call
aString.setCapacity then call the crashing function. I guess the reason it does
not crash before is when the capacilty set to 0 we used to allocation some
buffer for it but now change.

The patch is simple. Check the length = 0 condiction and return in the beginning
of the function

 87 void HankakuToZenkaku (
 88     const PRUnichar* aSrc, PRInt32 aLen, 
 89     PRUnichar* aDest, PRInt32 aDestLen, PRInt32* oLen)
 90 {
 91 
 92     PRInt32 i,j;
 93     // loop from the first to the last char except the last one.
 94     for(i = j = 0; i < (aLen-1); i++,j++,aSrc++, aDest++)
 95     {
[96...118, some code]
119     }
120 
121     // handle the last character
122     if(IS_HANKAKU(*aSrc)) 
123          *aDest = gBasicMapping[(*aSrc) - 0xff60];
124     else
125          *aDest = *aSrc;
126 
127     *oLen = j+1;
128 }

Comment 16

[Alec Flett]

Comment on attachment 124742 [details] [diff] [review]
patch fix crash

sr=alecf

Comment 17

[Samir Gehani]

a=adt to land this on the 1.4 branch once you get drivers' approval.  Please add
the fixed1.4 keyword once you land this fix.

Comment 18

[Asa Dotzler [:asa]]

Comment on attachment 124742 [details] [diff] [review]
patch fix crash

a=asa (on behalf of drivers) for checkin to the 1.4 branch.

Comment 19

[Frank Tang]

fixed and check in at Jun 3, 2003  13:25. Somehow I fogot to login mozilla when
I change the state to fixed1.4 and FIXED so the bug still say it is new. 

Comment 20

[ji]

the crash is verified as fixed in 2003060508 1.4 branch build.
But the Ja filename is not MIME encoded. Filed a separate bug as bug 208476

Comment 21

[Paul Wyskoczka]

Marking verified1.4

Comment 22

[Asa Dotzler [:asa]]

mozilla1.4 shipped. unsetting blocking1.4 request.