Closed Bug 97585 Opened 23 years ago Closed 23 years ago

A mail reply freezes whole application

Categories

(SeaMonkey :: MailNews: Message Display, defect)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.5

People

(Reporter: hajo, Assigned: sspitzer)

References

Details

(Keywords: hang, Whiteboard: PDT+)

Attachments

(1 file)

patch
3.07 KB, patch
bugzilla
: review+
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3+) Gecko/20010820
BuildID:    2001082922

A reply (reply button, or right mouse button action) to a quite normal ascii
mail freezes mozilla
. CPU load goes to 99%

Reproducible: Always
Steps to Reproduce:
1.start mail window
2.view mail
3.click REPLY
Hajo, can you send this email to me please? and also attach it as an attachment
here in this bugzilla bug if possible. Also, could you try to reproduce with a
later build?

Thanks
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: hang
Summary: a mail reply freezes hole application → A mail reply freezes hole application
dup of bug 96911?
Correcting typo in summary.
Summary: A mail reply freezes hole application → A mail reply freezes whole application
Yepp, it's the same behaviour, as discribed in bug #96911. I can reproduce the
freezes by starting the mail composer for a reply and a new message!
Unfortunately the error is equal with mail client from build ID 2001083108 
The fix wasn't checked in untill the day after, on Sept. 1st. Marking dup.
Please add comment or reopen if you see this in builds from Sept. 2nd or later.

*** This bug has been marked as a duplicate of 96911 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
This is not a dup of 96911. Despite a lot of confusing banter in that bug, the
only thing that got fixed by cls's & kin's was the crash.  The hang is still
there.  

Interestingly, I see this problem on my RedHat 6.x machine, but not on my RedHat
7.x machine.

IMHO this should be a blocker, since Leif has been seeing this as well and it's
preventing him from getting work done.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
OK, so after going in with gdb, I managed to track down a key part of the
problem, in my case anyway.

Due to lossage of some unknown cause (fsck?  Linux?  Mozilla?  something else?)
~/.signature in my home directory was a directory rather than a regular file.  

Some versions of mozilla were hanging trying to do a seek to the beginning of
the file while trying to read it to look for any charset encoding tags.

it could have been mozilla that created that directory.  see bug #66668

as far as what changed recently exposed the hang, it sounds like #91670.

I'll work on making it so in the case where your sig file is a dir, we don't hang.
Status: REOPENED → ASSIGNED
ok, I've got a fix for the infinite loop, but I think the real problem is that 
different platforms behave differently with this code:

  nsFileSpec fSpec points to a dir.
  nsInputFileStream tempFile(fSpec);
  tempFile.is_open() is false on win2k, true on linux.

that difference makes it so on windows, nsMsgCompose::LoadDataFromFile() bails 
out with an error, linux keeps on trunking.

I'll spin off a seperate bug on this platform issue, and attach my patch to 
prevent this problem altogether by checking if the file spec is a directory or 
not.

Confirmed that it doesn't crash when removing the ~/.signature/ directory.
Comment on attachment 48265 [details] [diff] [review]
patch

Looks good but I don't thing reporting "Error reading file" will really help the user. Instead, I think it would be better to report an NS_MSG_UNABLE_TO_OPEN_FILE error and set the file name into the Error reporting system. Look for other occurance of NS_MSG_UNABLE_TO_OPEN_FILE in the code...
Attachment #48265 - Flags: needs-work+
QA Contact: esther → sheelar
ducarroz, I defined the error string for completeness.

in this case, the user never sees any error message.

If we want to pop up an alert in the case where we fail to open the users .sig,
let's spin that off to another bug.
ok, if we never show an error to the user, I am fine with your patch. Now, do we
need to show an alert! I am not sure, this is a very special case and I don't
think it worst to do it, at least in a near future. Up to you to decide if you
want to file a bug.
Comment on attachment 48265 [details] [diff] [review]
patch

R=ducarroz
Attachment #48265 - Flags: needs-work+ → review+
ok, sr=bienvenu
fix landed on the trunk.
Hi, no more crashes!!!
I can't reproduce the bug on my unchanged system! I'm trying build 2001090921!
Remark! I've got an empty .signature directory.
Congratulations
hm, could bug 97474 be a dup of this [or, vice versa]? [i still encounter bug
97474 when using a recent branch build...]
*** Bug 97474 has been marked as a duplicate of this bug. ***
with a moz trunk debug from this morning, this is not a problem for me.

nbaca, what's the buildid for the trunk build you saw this in? (unless i misread
you earlier today over IM... :)
definetly something we want for the branch.
Keywords: nsbranch+
Target Milestone: --- → mozilla0.9.5
Blocks: 99508
hokay, this wfm using 2001.09.14.08-trunk comm bits [using a pop acct to an
isp].
Tested the origin bug with release 0.9.4 build 2001091311!
Arghhh! Mozilla freezes, if I try to open the mail composer!
I've got an empty .signature directory in my home dir!
If I delete the directory! Mozilla doesn't hang!
Trunk for build 2001090921 see comment "2001-09-10 03:19", there are no freezes
with the .signature directory!
*** Bug 100034 has been marked as a duplicate of this bug. ***
*** Bug 100035 has been marked as a duplicate of this bug. ***
this bug was plussed at the PDT meeting on Friday. I forgot to mark it as such.
Whiteboard: PDT+
*** Bug 98886 has been marked as a duplicate of this bug. ***
fixed on trunk and branch.  marking fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
*** Bug 100070 has been marked as a duplicate of this bug. ***
Branch build 2001-09-19-05: Linux RH 7.1, Fixed.
With this build I open Mail, select New Msg button, move the new message/compose
window on the screen and it's ok.

Adding keyword "vtrunk", it needs to be verified on the trunk.
Keywords: vtrunk
*** Bug 100730 has been marked as a duplicate of this bug. ***
Removing keyword.  Verified this on 2001-11-07-06 build Linux RH 6.2
Status: RESOLVED → VERIFIED
Keywords: vtrunk
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: