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

RESOLVED EXPIRED

Status

SeaMonkey
MailNews: Message Display
RESOLVED EXPIRED
16 years ago
8 years ago

People

(Reporter: Brian Rogers, Unassigned)

Tracking

({testcase})

Trunk
x86
Windows 2000
testcase

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

16 years ago
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.
(Reporter)

Comment 1

16 years ago
Created attachment 110306 [details]
Simplified testcase: will lock up Mozilla
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

16 years ago
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: <sc2-cvs-admin@lists.sourceforge.net>
Delivered-To: burpmaster@truffula.net
From: meep-eep@users.sourceforge.net
To: sc2-cvs@lists.sourceforge.net
Subject: test
Sender: sc2-cvs-admin@lists.sourceforge.net
Date: Sat, 28 Dec 2002 12:45:28 -0800

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

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()
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

16 years ago
Created attachment 111185 [details]
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

16 years ago
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.
*** Bug 190851 has been marked as a duplicate of this bug. ***
accepting.
Status: NEW → ASSIGNED
Flags: blocking1.3b?
QA Contact: laurel → esther
Target Milestone: --- → mozilla1.3beta
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.
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.
Keywords: nsbeta1+
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.
benb, any suggestions on how to fix this?
see bug #190879 for the "fix FindChar() issue"
Created attachment 112819 [details] [diff] [review]
wall paper patch, until I can track this down.

Comment 16

16 years ago
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.
Attachment #112819 - Flags: superreview+

Comment 17

16 years ago
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.
Attachment #112819 - Flags: approval1.3b+
ok, wall paper fix checked in.

now this is an assert.

I'll keep the bug open until we have a real fix.
Summary: E-mail message locks up Mozilla with 100% CPU usage → E-mail message asserts (use to hang) in mozTXTToHTMLConv
Flags: blocking1.3b?
Comment on attachment 112819 [details] [diff] [review]
wall paper patch, until I can track this down.

checked in.
Attachment #112819 - Attachment is obsolete: true
no longer a hang, no longer critical, but we should fix it.
Severity: critical → major
Keywords: hang, nsbeta1+
Summary: E-mail message asserts (use to hang) in mozTXTToHTMLConv → E-mail message asserts (used to hang) in mozTXTToHTMLConv
untargeting, for now.
Severity: major → normal
Target Milestone: mozilla1.3beta → ---
Product: Browser → Seamonkey

Comment 23

14 years ago
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].
(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

14 years ago
(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

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

Updated

13 years ago
Assignee: sspitzer → mail
Status: ASSIGNED → NEW
Assignee: mail → nobody
QA Contact: esther → message-display

Comment 27

9 years ago
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
Status: NEW → UNCONFIRMED

Comment 28

9 years ago
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

9 years ago
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

8 years ago
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
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.