97474 - hang opening mail compose window

Status: VERIFIED DUPLICATE of bug 97585

(MailNews Core :: Composition, defect)

Description

[Chris Waterson]

Somehow I've managed to get my profile into a state where opening the mail
compose window on with a trunk build causes a hang, apparently an infinite loop.
The problem goes away if I create a new profile. I've removed localstore.rdf so
that's not it. I'll attach a stack trace, and try to debug a bit.

Comment 1

[Chris Waterson]

Attachment: snapshot of stack on main thread while hung

Comment 2

[Chris Waterson]

Okay, so the problem appears to be that the loop in

 nsMsgI18NParseMetaCharset(nsFileSpec* fileSpec)

(around line 556 in nsMsgI18N.cpp) never terminates. Still digging.

Comment 3

[Chris Waterson]

Okay, discovered the problem. I have a _directory_ called ``.signature'' in my
home directory, and my profile has somehow managed to decide that this should be
my sig file.

Ideally, we'd fix the logic in nsMsgCompose::LoadDataFromFile() should probably
be fixed to _not_ use nsFileSpec, which is conveniently trying to read data
using PR_Read() from a directory inode. Realistically, I suspect just doing some
nsFileSpec trickery to ensure that the sig file is not a directory would suffice.

Comment 4

[Doug Turner (:dougt)]

how about adding a simple call to IsFile() - you pick your error code?

Index: nsMsgCompose.cpp
===================================================================
RCS file: /cvsroot/mozilla/mailnews/compose/src/nsMsgCompose.cpp,v
retrieving revision 1.280
diff -u -r1.280 nsMsgCompose.cpp
--- nsMsgCompose.cpp	2001/08/22 00:02:01	1.280
+++ nsMsgCompose.cpp	2001/08/30 03:16:05
@@ -2559,6 +2559,9 @@
   char          *readBuf;
   char          *ptr;
 
+  if (!fSpec.IsFile())
+    return NS_MSG_ERROR_WRITING_FILE;
+
   nsInputFileStream tempFile(fSpec);
   if (!tempFile.is_open())
     return NS_MSG_ERROR_WRITING_FILE;        

Comment 5

[sairuh (rarely reading bugmail)]

interesting, i haven't seen this till recently... [sidenote: my ~/.signature dir
has been around for some time --last modified in july 2000. just wondering why
this is cropping up now... regression?]

Comment 6

[Brendan Eich [:brendan]]

This just burned me today.  I have no idea what created my .signature directory,
but it's empty.  Here's a stack backtrace of where my optimized trunk build
(from last night's checkout) hung:

#0  0x40573fc4 in __libc_lseek () from /lib/i686/libc.so.6
#1  0x401e76d8 in __DTOR_END__ () at eval.c:41
#2  0x401c096c in _MD_lseek () at eval.c:41
#3  0x401bc516 in pt_Available_f () at eval.c:41
#4  0x401aae97 in PR_Available () at eval.c:41
#5  0x40116337 in FileImpl::Seek () at eval.c:41
#6  0x40114d11 in nsRandomAccessInputStream::readline () at eval.c:41
#7  0x41ca36d3 in nsMsgI18NParseMetaCharset ()
   from /home/brendan/src/trunk-opt/mozilla/dist/bin/libmsgbaseutil.so
#8  0x41afbc6d in nsMsgCompose::LoadDataFromFile ()
   from
/home/brendan/src/trunk-opt/mozilla/dist/bin/components/libmsgcompose.so#9
0x41afbaa7 in nsMsgCompose::ConvertTextToHTML ()
   from
/home/brendan/src/trunk-opt/mozilla/dist/bin/components/libmsgcompose.so#10
0x41afc3fd in nsMsgCompose::ProcessSignature ()
   from
/home/brendan/src/trunk-opt/mozilla/dist/bin/components/libmsgcompose.so#11
0x41afcac0 in nsMsgCompose::BuildBodyMessageAndSignature ()
   from
/home/brendan/src/trunk-opt/mozilla/dist/bin/components/libmsgcompose.so#12
0x41afb8fb in nsMsgDocumentStateListener::NotifyDocumentCreated ()
   from
/home/brendan/src/trunk-opt/mozilla/dist/bin/components/libmsgcompose.so#13
0x41d0dfde in nsEditor::NotifyDocumentListeners ()
   from /home/brendan/src/trunk-opt/mozilla/dist/bin/components/libeditor.so
#14 0x41d082a5 in nsEditor::PostCreate ()
   from /home/brendan/src/trunk-opt/mozilla/dist/bin/components/libeditor.so
#15 0x41d49870 in nsHTMLEditor::PostCreate ()
   from /home/brendan/src/trunk-opt/mozilla/dist/bin/components/libeditor.so
#16 0x41d2fdb1 in nsEditorShell::PrepareDocumentForEditing ()
   from /home/brendan/src/trunk-opt/mozilla/dist/bin/components/libeditor.so
#17 0x41d3d8ab in nsEditorShell::EndPageLoad ()
   from /home/brendan/src/trunk-opt/mozilla/dist/bin/components/libeditor.so
#18 0x41d3d036 in nsEditorShell::OnStateChange ()
   from /home/brendan/src/trunk-opt/mozilla/dist/bin/components/libeditor.so
#19 0x40c7e00b in nsDocLoaderImpl::FireOnStateChange ()
   from /home/brendan/src/trunk-opt/mozilla/dist/bin/components/liburiloader.so
#20 0x40c7d55c in nsDocLoaderImpl::doStopDocumentLoad ()
   from /home/brendan/src/trunk-opt/mozilla/dist/bin/components/liburiloader.so
#21 0x40c7d42b in nsDocLoaderImpl::DocLoaderIsEmpty ()
   from /home/brendan/src/trunk-opt/mozilla/dist/bin/components/liburiloader.so
#22 0x40c7d29e in nsDocLoaderImpl::OnStopRequest ()
   from /home/brendan/src/trunk-opt/mozilla/dist/bin/components/liburiloader.so
#23 0x40798a36 in nsLoadGroup::RemoveRequest ()
   from /home/brendan/src/trunk-opt/mozilla/dist/bin/components/libnecko.so
#24 0x40793d2e in nsStreamIOChannel::OnStopRequest ()
   from /home/brendan/src/trunk-opt/mozilla/dist/bin/components/libnecko.so
#25 0x407e7f0d in nsOnStopRequestEvent::HandleEvent ()
   from /home/brendan/src/trunk-opt/mozilla/dist/bin/components/libnecko.so
#26 0x4079c9fb in nsARequestObserverEvent::HandlePLEvent ()
   from /home/brendan/src/trunk-opt/mozilla/dist/bin/components/libnecko.so
#27 0x40130bb7 in PL_HandleEvent () at eval.c:41
#28 0x40131004 in PL_ProcessEventsBeforeID () at eval.c:41
#29 0x40c9f479 in processQueue ()
   from
/home/brendan/src/trunk-opt/mozilla/dist/bin/components/libwidget_gtk.so#30
0x401007fd in nsVoidArray::EnumerateForwards () at eval.c:41
#31 0x40c9f4b7 in nsAppShell::ProcessBeforeID ()
---Type <return> to continue, or q <return> to quit---

JFD, is this your bug?  If not, let's get it reassigned.

Nominating for 0.9.4 in case there's a low-risk fix to this hang (which is just
as severe as a crash, and which can lose data if you have other composer windows
open with unsaved data in them).

/be

Comment 7

[sairuh (rarely reading bugmail)]

could bug 97585 be related, or a dup?

still seeing this using today's branch bits...and nbaca also sees it with recent
branch and trunk bits.

Comment 8

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

I think I fixed this recently, at least on the trunk.  let me find the bug.

Comment 9

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

yes, this smells like #97585

chris, can you try a trunk build?  also, can you look at your settings to see 
if somehow your signature pref is set to a directory?

Comment 10

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

reading all the comments, this is clearly a dup.

I'll land my fix on the branch.


*** This bug has been marked as a duplicate of 97585 ***

Comment 11

[Sheela Ravindran]

verify as dup