677360 - ASSERTION: length mismatch: 'calculator.Length() == converter.Length()' failure

Status: UNCONFIRMED

(Core :: XPCOM, defect)

Description

[Kent James (:rkent)]

I'm getting this in a debug build of Thunderbird, with the comm-aurora repository at  8165:56aa3a1b61e2, and mozilla-aurora at 72744:1539927cf9ba  I have quite a bit of detail of this, so I'll record that in case it will be useful in fixing.

The error is occurring while Thunderbird is trying to get the attachment of an IMAP spam message, for stack see bug 668944 comment 29.

I have details of the text that is being fed into xpcom and leading to the assertion.

In xpcconvert.cpp this line:

                    jschar *p = (jschar *)UTF8ToNewUnicode(*cString, &len);
                    
*cString.mData is:

0x0E37BCE8  46 77 64 3a 20 50 72 6f 66 69 74 65 7a 20 64 65 73 20 6a  Fwd: Profitez des j
0x0E37BCFB  65 75 78 20 61 75 20 6a 61 63 6b 70 6f 74 20 70 72 6f 67  eux au jackpot prog
0x0E37BD0E  72 65 73 73 69 66 20 67 72 e2 63 65 20 61 75 20 62 6f 6e  ressif grâce au bon
0x0E37BD21  75 73 20 64 65 20 62 69 65 6e 76 65 6e 75 65 20 70 6f 75  us de bienvenue pou
0x0E37BD34  72 20 6c 65 73 20 6e 6f 75 76 65 61 75 78 20 6a 6f 75 65  r les nouveaux joue
0x0E37BD47  75 72 73 2e 2e 65 6d 6c 00 cd cd cd cd cd cd cd cd cd cd  urs..eml.ÍÍÍÍÍÍÍÍÍÍ

returned length is 101  However, *p is:

0x079C9218  46 00 77 00 64 00 3a 00 20 00 50 00 72 00 6f 00 66  F.w.d.:. .P.r.o.f
0x079C9229  00 69 00 74 00 65 00 7a 00 20 00 64 00 65 00 73 00  .i.t.e.z. .d.e.s.
0x079C923A  20 00 6a 00 65 00 75 00 78 00 20 00 61 00 75 00 20   .j.e.u.x. .a.u. 
0x079C924B  00 6a 00 61 00 63 00 6b 00 70 00 6f 00 74 00 20 00  .j.a.c.k.p.o.t. .
0x079C925C  70 00 72 00 6f 00 67 00 72 00 65 00 73 00 73 00 69  p.r.o.g.r.e.s.s.i
0x079C926D  00 66 00 20 00 67 00 72 00 00 00 cd cd cd cd cd cd  .f. .g.r...ÍÍÍÍÍÍ
0x079C927E  cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd  ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ

So something is going wrong with the decoding of "grâce"

This line starts the code that leads to the assertion:

                    JSString* jsString =
                        JS_NewExternalString(cx, p, len,
                                             sXPCOMUCStringFinalizerIndex);

I see:

###!!! ASSERTION: length mismatch: 'calculator.Length() == converter.Length()',
file c:/tb/aurora/src/mozilla/xpcom/string/src/nsReadableUtils.cpp, line 402
Assertion failure: chars[length] == 0, at c:\tb\aurora\src\mozilla\js\src\vm/Str
ing-inl.h:171

Comment 1

[Jonathan Protzenko [:protz]]

That would explain the random reading in the memory described in bug 676882. Can you try out with a fresh comm-central build see if this is fixed?

Comment 2

[Kent James (:rkent)]

Is there some specific patch that you expect fixes it?

Comment 3

[Jonathan Protzenko [:protz]]

The patch that I commited in bug 676882

Comment 4

[Kent James (:rkent)]

That's why I asked. First, I don't see any evidence that you committed that patch. Second, your patch seems to deal with a munged subject, but this issue of mine (which probably has the same root cause) is in the title of the attachment (which happens to be a message that SpamAssassin converted into an attachment).

But I will test it anyway.

Comment 5

[Jonathan Protzenko [:protz]]

I'm sorry I meant bug 674488. I'll commit the patch in bug 676882 tomorrow so you might want to wait until then. Sorry for the confusion.

Comment 6

[Kent James (:rkent)]

The problem does not occur with Thunderbird trunk 8266:ef977dca2337 (which I think means bug 674488 landed but not bug 676882)

To the XPCOM types: this just means that Thunderbird has a workaround, the core bug presumably still exists.

Comment 7

[Jonathan Protzenko [:protz]]

Absolutely, the core bug still lurks around.