964182 - After landing of Bug 920725 fix SM, Thunderbird and Firefox still crashing with same signature

Status: RESOLVED DUPLICATE of bug 986548

(Core :: DOM: HTML Parser, defect)

Description

[Misak Khachatryan]

Example crash report ID is a451a278-a2db-471e-989f-b7a702140124

Steps to reproduce:

1. Set up SM mailnews like this:

             In mailnews add any RSS account. Ensure that there are unread messages.

2. Start SM
3. Go to mailnews
4. Click on any folder on Local Folders.
5. Press Space until SM asks to go to next message, which should be in RSS feed.
6. Answer Yes
7. Segfault

Comment 1

[Steve Workman [:sworkman] (INACTIVE)]

Misak, thanks for the info. I have this on my radar now and will get to it when I have some time.

Comment 2

[Steve Workman [:sworkman] (INACTIVE)]

Able to reproduce this consistently on seamonkey trunk/nightly, Build ID 20140131003001. I downloaded symbols from the server for a gdb run and could see the stack trace identified in the crash report. But no symbols for variables, so I did a debug build locally.

On a debug build, seamonkey is crashing consistently in EncodingUtils::DecoderForEncoding, in MOZ_ASSERT(decoder). This assert isn't called in release builds, of course; so I commented it out and tried running again. I see the same crash I saw in the nightly build and the one seen in the crash report.

So, this looks a little different that the stack trace we saw in bug 920725. In that one the crash was due to a null mLastBuffer pointer and happening during the call to mLastBuffer->getEnd() in WriteStreamBytes (http://hg.mozilla.org/releases/mozilla-beta/annotate/7d23197d995a/parser/html/nsHtml5StreamParser.cpp#l805).

This crash is later in that function, and is because mUnicodeDecoder is null (http://hg.mozilla.org/mozilla-central/annotate/b9d9649e7ec0/parser/html/nsHtml5StreamParser.cpp#l823).

Henri, I'm not convinced that this is related to the off-main-thread OnDataAvailable work, but the crash trace and occurence of the crashes is similar to 920725. What's your opinion? It might be related to your patch in bug 960519 as well.

Comment 3

[Steve Workman [:sworkman] (INACTIVE)]

Some more debug info - I put a breakpoint before the MOZ_ASSERT(decoder) in the debug build.

(gdb) print aEncoding
$2 = (const nsACString_internal &) @0x7fffd1330b50: {mData = 0x7ffff51e5e60 <gNullChar> "", mLength = 0, mFlags = 1}
(gdb) print contractId
$3 = {<nsFixedCString> = {<nsCString> = {<nsACString_internal> = {mData = 0x7fffd27fe990 "@mozilla.org/intl/unicode/decoder;1?charset=", mLength = 44, mFlags = 65553}, <No data fields>}, 
    mFixedCapacity = 63, mFixedBuf = 0x7fffd27fe990 "@mozilla.org/intl/unicode/decoder;1?charset="}, 
  mStorage = "@mozilla.org/intl/unicode/decoder;1?charset=\000\177\000\000\360\351\177\322\377\177\000\000\216\301J\360\377\177\000"}

Looks like nsHtml5StreamParser::mCharset isn't set yet? Could this be a race condition with the Off-Main-Thread code?

Comment 4

[Henri Sivonen (:hsivonen)]

(In reply to Steve Workman [:sworkman] from comment #3)
> Looks like nsHtml5StreamParser::mCharset isn't set yet? Could this be a race
> condition with the Off-Main-Thread code?

If deleting nsHtml5StreamParser can lead to the memory that previously belonged to mCharset looking like an empty string, yes.

Comment 5

[Henri Sivonen (:hsivonen)]

I wouldn't spend time chasing this before seeing what effect bug 960519 has.

Comment 6

[Steve Workman [:sworkman] (INACTIVE)]

Sounds like a plan.

Comment 8

[Misak Khachatryan]

This bug is now appearing in 2.25, which is latest stable version, so I expect huge user impact.

Comment 9

[Philip Chee]

(In reply to Misak Khachatryan from comment #8)
> This bug is now appearing in 2.25, which is latest stable version, so I
> expect huge user impact.
So can someone either land Bug 960519 or alternatively start looking into fixing it here in this bug?

Comment 10

[Steve Workman [:sworkman] (INACTIVE)]

Henri was investigating oranges on try in bug 960519 comment 7. I know he's very busy, but we probably have to wait on him since he know much more about the parser than I do.

Comment 11

[Misak Khachatryan]

I tried patch from bug 960519 whet it comes first, it's not helping.

Comment 12

[Henri Sivonen (:hsivonen)]

(In reply to Steve Workman [:sworkman] from comment #10)
> Henri was investigating oranges on try in bug 960519 comment 7. I know he's
> very busy, but we probably have to wait on him since he know much more about
> the parser than I do.

Landing that one is high up on my todo list. Sorry for it taking so long.

(In reply to Misak Khachatryan from comment #11)
> I tried patch from bug 960519 whet it comes first, it's not helping.

In that case, I have no clue what this crash is about. :-(

Comment 13

[Misak Khachatryan]

It doesn't apply now to recheck, maybe I should do clobber first on that time.

Comment 14

[Misak Khachatryan]

Well, bug 920725 fixed, but crash still here :(

Comment 15

[Henri Sivonen (:hsivonen)]

The bug summary says "Firefox". Can anyone reproduce this crash in a Firefox nightly build that's fresh enough to have the fix for bug 960519 included?

Comment 16

[David Edwards]

976449 was marked as a duplicate of this. That crash is still happening with Seamonkey build from comm-central, so 920725 hasn't fixed it.

Comment 17

[David Edwards]

Sorry, that was supposed to read 960519, not 920725.

Comment 18

[Henri Sivonen (:hsivonen)]

(In reply to David Edwards from comment #16)
> 976449 was marked as a duplicate of this.

I reopened that one.

Per comment 15 here, I'd still like to know if this bug can be reproduced in *Firefox* Nightly nowadays.