MIME_DecodeMimePartIIStr caused illegal nsString usage.

VERIFIED FIXED in M15

Status

MailNews Core
Internationalization
P3
normal
VERIFIED FIXED
18 years ago
9 years ago

People

(Reporter: Frank Tang, Assigned: nhottanscp)

Tracking

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
When I turn on the nsString illegal usage detection code (see 28424) and open my
mailbox (IMAP4), I hit the following problme. the nsMsgDatabase::YarnTonsString
passing char* to nsString in a illegal way. The nsString can only handle ASCII
value in char* but not other data from 0x80-0xFF without proper conversion. Here
is the stack trace

...


NTDLL! 77f662ac()
nsDebug::Assertion(const char * 0x100a71bc, const char * 0x100a71ac, const char
* 0x100a7184, int 0x0000013a) line 189 + 13 bytes
CopyChars2To1(char * 0x00129a5c, int 0x00000000, const char * 0x00129c58,
unsigned int 0x00000000, unsigned int 0x0000003c) line 314 + 31 bytes
nsStr::Append(nsStr & {...}, const nsStr & {...}, unsigned int 0x00000000, int
0x0000003c) line 171 + 50 bytes
nsCString::Append(const nsStr & {...}, int 0x0000003c) line 906 + 43 bytes
nsCAutoString::nsCAutoString(const nsStr & {...}) line 1801
nsMimeConverter::DecodeMimePartIIStr(nsMimeConverter * const 0x0766d5a0, const
nsString & {...}, nsString & {...}, nsString & {...}, int 0x00000001) line 65
nsMsgDatabase::RowCellColumnToMime2DecodedString(nsIMdbRow * 0x066152f8,
unsigned long 0x00000081, nsString & {...}) line 2389 + 58 bytes
nsMsgHdr::GetMime2DecodedSubject(nsMsgHdr * const 0x06616b10, nsString *
0x00129dc0) line 595
nsMessage::GetMime2DecodedSubject(nsMessage * const 0x076146c4, nsString *
0x00129dc0) line 273 + 33 bytes
nsMsgMessageDataSource::createMessageNameNode(nsIMessage * 0x076146c4, int
0x00000000, nsIRDFNode * * 0x00129f0c) line 912 + 22 bytes
nsMsgMessageDataSource::createMessageNode(nsIMessage * 0x076146c4,
nsIRDFResource * 0x03680080, nsIRDFNode * * 0x00129f0c) line 868 + 18 bytes
nsMsgMessageDataSource::GetTarget(nsMsgMessageDataSource * const 0x03680100,
nsIRDFResource * 0x076146b0, nsIRDFResource * 0x03680080, int 0x00000001,
nsIRDFNode * * 0x00129f0c) line 291 + 25 bytes
CompositeDataSourceImpl::GetTarget(CompositeDataSourceImpl * const 0x0353e490,
nsIRDFResource * 0x076146b0, nsIRDFResource * 0x03680080, int 0x00000001,
nsIRDFNode * * 0x00129f0c) line 708 + 28 bytes
...

The problem is MIME_DecodeMimePartIIStr is expecting nsString as charsetCstr but
it is an nsCAutoString. It will automatically convert it into nsString when it
should not. I think we need ot chagne the interface of MIME_DecodeMimePartIIStr
to make it take nsCString for the 2nd argument.

  nsCAutoString encodedStr(header);
  // apply MIME decode.
  decodedCstr = MIME_DecodeMimePartIIStr(encodedStr,
                                           charsetCstr, eatContinuations);

-	encodedStr	{...}
+	nsCString	{...}
+	mBuffer	0x00129a5c "?o??????l???????????i??????,?]?A???N,?@???????g??????^_^??."

This is a memory usage effectiency issue.
(Reporter)

Updated

18 years ago
Blocks: 28424
Summary: MIME_DecodeMimePartIIStr caused illegal nsString usage. → MIME_DecodeMimePartIIStr caused illegal nsString usage.
(Reporter)

Comment 1

18 years ago
sorry, I copy the first paragph from some other bug but forget to change it-
Ignore the "nsMsgDatabase::YarnTonsString" part, it is really in
MIME_DecodeMimePartIIStr
(Assignee)

Comment 2

18 years ago
Current interface takes input header as nsString. Since the input header is 
expected to be MIME encoded (i.e. us-ascii), it should be nsCString instead.

I think nsCString was not available at the time this interface was written. 
Also I think there is no data loss here because the input is always us-ascii but 
we want to avoid the constructor of nsCAutoString to be generated.

  // Decode routine (also converts output to unicode)
  NS_IMETHOD DecodeMimePartIIStr(const nsString& header, 
                                 nsString& charset, 
                                 nsString& decodedString,
				 PRBool eatContinuations = PR_TRUE) = 0;
Status: NEW → ASSIGNED
(Assignee)

Updated

18 years ago
Blocks: 32012

Comment 3

18 years ago
Do we call this for all headers?  If so, what happens if the header is not
MIME-compliant and contains non-ASCII?
(Assignee)

Comment 4

18 years ago
Implementation handles the non MIME encoded case. It uses the input charset 
(folder charset) and apply charset conversion (to unicode). Not just assign to 
nsString.

http://lxr.mozilla.org/seamonkey/source/mailnews/mime/src/nsMimeConverter.cpp#64
(Assignee)

Comment 5

18 years ago
I checked in a new member to nsIMimeConverter which takes nsCString for inputs 
(encoded header string and charset name) and returns nsString.
I didn't removed the old one and didn't change clients of the interfaces.

list of clients
msgdb - filed as a bug 32012
nsMsgHeaderParser and emitter - mscott, could you take care of this?
nsMsgI18N - I am going to do this

Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Target Milestone: M15

Comment 6

18 years ago
** Checked on 6/5/2000 **

A new member of nsIMimeConverter is in mailnews/mime/public/nsIMimeConverter.h.

Have the clients nhotta mentions in his 3/17/2000 comments been
take care of? I see Bug 32012 is stil open.  How about
nsMsgHeaderParser and nsMsgI18N? Is this issue still relevant?

In any case, the new method is there and so I will mark this
fix verified. 
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.