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?

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?).

Yes, see http://bugzilla.mozilla.org/show_bug.cgi?id=142930#c7

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

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

Filed bugscape 15323. Mark as invalid, since this is commercial only.

verified