187065 - E-mail message asserts (used to hang) in mozTXTToHTMLConv

Status: RESOLVED EXPIRED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Brian Rogers]

I received an e-mail message which locks up Mozilla build 2002122808 on Win2k.
I've narrowed it down to the line
"That, my children, is an entirely different
story.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"

I suspect this is the fault of the code that styles the patterns *bold* and
/italic/, as well as makes e-mail addresses links.  In this case, it would be
the '@' signs, which it might be seeing as an e-mail address to linkify.

Comment 1

[Brian Rogers]

Attachment: Simplified testcase: will lock up Mozilla

Comment 2

[Matthias Versen [:Matti]]

I can confirm the hang with the testcase with todays win2k trunk cvs build but
my debug build doesn't hang ! (compiled at the same time)

Comment 3

[Brant Gurganus]

reproduced on win xp sp1
manual Talkback ID: TB15602601Q

I found it weird since whenever I open .eml files, they open in the Browser and
not Mail and News.

No hang by Outlook Express

Message Source from Outlook Express:
Return-Path: <[e-mail]>
Delivered-To: [e-mail]
From: [e-mail]
To: [e-mail]
Subject: test
Sender: [e-mail]
Date: Sat, 28 Dec 2002 12:45:28 -0800

"That, my children, is an entirely different
story.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"

Comment 4

[(not reading, please use [e-mail] instead)]

I haven't gotten a stack for this yet.  (the talkback report didn't have a
stack, and I can't reproduce with my debug build.)

here's what I got, when attaching to an opt build:

XPCOM! 611464ec()
XPCOM! 6117e547()
NECKO! 609a3e21()
NECKO! 609a47c9()
NECKO! 609a5c3c()
NECKO! 609a5f16()
MIME! 607653e6()
MIME! 6075e297()
MIME! 6075e019()
MIME! 6075ddee()
MIME! 6075eae0()
MIME! 6075b5ef()
MIME! 60752d19()
URILDR! 60ca5f8e()
NECKO! 6098cffd()
NECKO! 6098bf2d()
XPCOM! 61174616()
SETUPAPI! 778b0c24()

Comment 5

[Matthias Versen [:Matti]]

sspitzer: I have the same problem with my debug (see comment#2).
Do you know how to create a optimized build with symbols on win2k ?

Comment 6

[David Bradley]

Attachment: Stack of the infinite loop

In nsStringIterator.h

the infinite loop occurs here, one_hop == 0;

while ( n > 0 )
{
    difference_type one_hop = NS_MIN(n, size_forward());

    NS_ASSERTION(one_hop>0, "Infinite loop: can't advance a reading iterator
beyond the end of a string");
    // perhaps I should |break| if |!one_hop|?

    mPosition += one_hop;
    normalize_forward();
    n -= one_hop;
}

Comment 7

[David Bradley]

I think what's happening is that in mozTXTToHTMLConv::FindURL the string gets
modified (temp), but "pos" from the original string is being used in the call to
CompleteAbbreviatedURL at line 476.

Comment 8

[(not reading, please use [e-mail] instead)]

*** Bug 190851 has been marked as a duplicate of this bug. ***

Comment 9

[(not reading, please use [e-mail] instead)]

accepting.

Comment 10

[(not reading, please use [e-mail] instead)]

darin did some debugging for me, and determined that:

in mozTXTToHTMLConv::CompleteAbbreviatedURL,
pos was 410 and aInLength was 347

that's bad, since pos should be < aInLength!

we are calling FindChar() with pos past the end.

I'd think FindChar() should handle this more gracefully (and not infinite loop)

but mozTXTToHTMLConv should not be sending bogus values to FindChar().

I was able to reproduce this in a recent opt, mozilla build, but not my latest 
debug win32 opt mozilla build.  (I'll try linux)

I'll slap some double checking and asserting code into mozTXTToHTMLConv and 
talk to jag about FindChar.

Comment 11

[(not reading, please use [e-mail] instead)]

ok, I can reproduce this now on my debug bits.

I've got a wall paper patch, but I'll work on the real fix.

Comment 12

[(not reading, please use [e-mail] instead)]

yikes, I can reproduce this, and dbradely's seems to be right that the problem 
is pos was for the original string, but the temp string has been modified so 
pos isn't right.

in my test cause, I get here and the whitespace has been stripped out, 
shortening the string, so pos is now > length.

I haven't figured out a solution yet, I'm still trying to sort out what the 
mozTXTToHTMLConv should do in this scenario.

Comment 13

[(not reading, please use [e-mail] instead)]

benb, any suggestions on how to fix this?

Comment 14

[(not reading, please use [e-mail] instead)]

see bug #190879 for the "fix FindChar() issue"

Comment 15

[(not reading, please use [e-mail] instead)]

Attachment: wall paper patch, until I can track this down.

Comment 16

[Darin Fisher]

Comment on attachment 112819 [details] [diff] [review]
wall paper patch, until I can track this down.

sr=darin

with this patch in my debug build, the message was successfully copied to my
Drafts folder.	i hit the assertion maybe half a dozen times, but the copy in
my Drafts folder looks to be OK.

Comment 17

[Asa Dotzler [:asa]]

Comment on attachment 112819 [details] [diff] [review]
wall paper patch, until I can track this down.

a=asa (on behalf of drivers) for checkin to 1.3beta.

Comment 18

[(not reading, please use [e-mail] instead)]

ok, wall paper fix checked in.

now this is an assert.

I'll keep the bug open until we have a real fix.

Comment 19

[(not reading, please use [e-mail] instead)]

Comment on attachment 112819 [details] [diff] [review]
wall paper patch, until I can track this down.

checked in.

Comment 20

[(not reading, please use [e-mail] instead)]

Attachment: stack from darin

Comment 21

[(not reading, please use [e-mail] instead)]

no longer a hang, no longer critical, but we should fix it.

Comment 22

[(not reading, please use [e-mail] instead)]

untargeting, for now.

Comment 23

[Mike Cowperthwaite]

Seeing this assertion in Mozilla MailNews 1.8a5-1130:

Error: Unknown namespace prefix 'html'.  Ruleset ignored due to bad selector.
Source File: chrome://messenger/skin/messageBody.css
Line: 43

But this doesn't happen in TB, and it doesn't look to me like it's related to 
the stack in attachment 112828 [details].

Comment 24

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #23)
> Seeing this assertion in Mozilla MailNews 1.8a5-1130:

er, that's not an assertion, and it's the wrong file - note that this bug's
summary mentions mozTXTToHTMLConv, not messageBody.css. that css error is bug
130728.

Comment 25

[Mike Cowperthwaite]

(In reply to comment #24)
> er, that's not an assertion, and it's the wrong file - note that this bug's
> summary mentions mozTXTToHTMLConv, not messageBody.css. that css error is
> bug 130728.

I was less than clear.  I meant that the only error I see in the JavaScript 
console using the test case is the one I pasted; and I wondered whether anyone 
still saw the original error.

Since the error I do see already has its own bug, if the original problem for 
this bug no longer exists, then this should be closed.

Comment 26

[timeless]

at this point it's a code error which you'd only see in a debugger or assertion
message.

Comment 27

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 28

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 29

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 30

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420