Closed Bug 142930 Opened 22 years ago Closed 22 years ago

Message hangs Mozilla when read via news.

Categories

(MailNews Core :: Networking: NNTP, defect)

Product:
MailNews Core
Component:
Networking: NNTP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED INVALID

People

(Reporter: stephend, Assigned: nhottanscp)

References

(
URL
)

Details

(Keywords: hang)

Attachments

(1 file)

the message, copied to a local folder. save this a local folder, it will hang too.
897 bytes, text/plain
Details 
Build ID: 2002-05-07, Windows 2000 and Mac OS X 10.1.4 Commercial 1.0 Branch

Summary: Message hangs Mozilla when read via news.

Steps to Reproduce:

1.  Subscribe to news://news.mcom.com/netscape.public.test.
2.  Look for the posting from Kryptolus on 2/26/2002 entitled, "Re: Test".
3.  In Threaded mode, expand the twisty and attempt to read the 5/1/2002 message
from testing@testing.invalid.

Here is the Message ID:
news://news.mcom.com:119/87d6wf32mi.fsf@thebeast.bjonnes-software.no

Actual Results:

We hang.

Expected Results:

No hang.

Caveat: My trunk Mozilla build on Windows 2000 is fine and dandy.  Other users
on netscape.public.mozilla.mail-news report that my latest Performance Results
posting hangs for them.  Perhaps it's the same bug, perhaps not.
Here's the message source:

Is it because the the URL following the Path: isn't on the same line (ie, has a \n)?

Path:
pixie.netscape.com!newsfeed.netscape.com!unlisys!news.snafu.de!news.tele.dk!small.news.tele.dk!193.213.112.26!newsfeed1.ulv.nextra.no!nextra.com!news2.ulv.nextra.no.POSTED!53ab2750!not-for-mail
Sender: larsbj@thebeast.bjonnes-software.no
Newsgroups: netscape.public.test
Subject: Test
From: testing@testing.invalid =?iso-8859-1?q?=E6=F8=E5?=
Message-ID: <87d6wf32mi.fsf@thebeast.bjonnes-software.no>
Lines: 7
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
NNTP-Posting-Host: 80.212.231.232
X-Complaints-To: news-abuse@nextra.no
NNTP-Posting-Date: Thu, 02 May 2002 00:51:14 MEST
X-Trace: news2.ulv.nextra.no 1020293474 80.212.231.232
Date: Wed, 01 May 2002 22:51:14 GMT


זרו

test

this hangs on the 1.0 branch and works on the trunk - I suspect it might be a
dup of a mime header parsing bug
yes, it's branch only.

bienvenu, ducarroz, scott:  any idea which mime header parsing bug this is a 
dup of?
Status: NEW → ASSIGNED
I looked around for a bit, but couldn't find it. I'd bet anything though, that
it's a dup.
I just updated and rebuilt my mozilla branch build, debug.

no crash.

donner, do you see this with an an opt, mozilla branch build?
Crap - oddly enough, I don't see this with the same profile, branch:

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020507

Mozilla Windows 2000 build.
>mime header parsing bug
bug 134277? But that is not checked in to the trunk either.
I am looking at it...
Using a Windows Release Commercial build, I was able to get the following stack
trace by breaking in the application while it was frozen:

XPCOM! 6116f235()
XPCOM! 611734f8()
XPCOM! 611325e0()
ADDRBOOK! 04db2b8c()
ADDRBOOK! 04db2c1f()
IMGLUE! 60642636()
XPCOM! 61166a4a()
XPC3250! 60d3239c()
XPC3250! 60d3591b()
JS3250! 60e2a42f()
JS3250! 60e2f4cf()
JS3250! 60e2a46c()
XPC3250! 60d2fdc5()
XPC3250! 60d2e743()
XPCOM! 61165f25()
EMITTER! 60211ba4()
EMITTER! 60211d3e()
MIME! 60741881()
MIME! 60741719()
MIME! 6074438e()
MIME! 607442fa()
MIME! 6073e8d6()
MIME! 60732b32()
URILDR! 60c85fa1()
NECKO! 6096ce69()
MSGNEWS! 609237f4()
MSGNEWS! 609238fe()
MSGNEWS! 609279ed()
MSGBSUTL! 60f31303()
NECKO! 6096bf83()
XPCOM! 61163b6a()

By the fact we are going through AIMGlue, I would suspect we are trying to
detect if the sender is current using AIM! That would explain why you cannot
reproduce this problem using a Mozilla build (is it true?).
FYI, bug 139842 was also MIME header parsing bug, this has been checked in to
both trunk and branch.

good work, JF, yes, I couldn't do it with a mozilla build.
my problem is that I have removed the aimstat.dll which took care of the AIM
buddy icon but I still hang with the same stack trace!!! Need to find out why
the emitter  access the aimglue!!
the stack trace should correspond to:

nsMimeHtmlDisplayEmitter::WriteHTMLHeaders     <-- MIME EMITTERS
  headerSink->ProcessHeaders()
    processHeaders()                           <-- MSGHDRVIEWOVERLAY
      ???

I was able to reproduce with my commercial branch build.
The infinite loop is bug 132583. I think that bug has to be fixed soon.
I have a call stack but I am not sure if I can paste the one of commerical build.
I will e-mail to ducarroz, bienvenu, sspitzer.

I'm rebuilding now, so that I can debug.

thanks for the info, ducarroz, nhotta.
over to nhotta, he's got this debugged, and has reduced it to depend on #132583
Assignee: sspitzer → nhotta
Status: ASSIGNED → NEW
Depends on: 132583
part of the call stack

nsReadingIterator<char>::normalize_forward() line 371 + 36 bytes
nsReadingIterator<char>::advance(int 1) line 179
nsCharSourceTraits<nsReadingIterator<char> >::advance(nsReadingIterator<char> &
{...}, int 2) line 408
copy_string(nsReadingIterator<char> & {...}, const nsReadingIterator<char> &
{...}, ConvertUTF8toUCS2 & {...}) line 92 + 13 bytes
NS_ConvertUTF8toUCS2::Init(const nsACString & {...}) line 1330 + 35 bytes
NS_ConvertUTF8toUCS2::NS_ConvertUTF8toUCS2(const char * 0x0012e098) line 528 +
21 bytes
nsAddrDatabase::GetRowFromAttribute(const char * 0x056735d8, const char *
0x0012e098, int 0, nsIMdbRow * * 0x0012e008) line 3106
nsAddrDatabase::GetCardFromAttribute(nsAddrDatabase * const 0x0578b3a8,
nsIAbDirectory * 0x05698884, const char * 0x056735d8, const char * 0x0012e098,
int 0, nsIAbCard * * 0x0012e2a8) line 3127 + 24 bytes
Status: NEW → ASSIGNED
Keywords: nsbeta1
Filed bugscape 15323.

Mark as invalid, since this is commercial only.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
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.

Attachment

General

Creator:
Created:
Updated:
Size: