Closed Bug 82643 Opened 23 years ago Closed 23 years ago

Replying to a message fails

Categories

(MailNews Core :: Composition, defect, P1)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.1

People

(Reporter: scottputterman, Assigned: mscott)

References

Details

(Keywords: dataloss, Whiteboard: wanted for 0.9.1 [nsbeta1+], fix in hand r=?, sr=?)

Attachments

(2 files)

using 2001052404. I have a message that when I reply to it, the status bar says sending message and the throbber keeps going. Eventually I get a message saying the server timed out. I will attach the message shortly.
nominating nsbeta1. I message we cannot send is a dataloss
Status: NEW → ASSIGNED
Keywords: dataloss, nsbeta1
Priority: -- → P1
Whiteboard: [nsbeta1+]
Target Milestone: --- → mozilla0.9.2
I'm putting this in 0.9.2 because this has hit me once out of many, many messages. But, if you can get a safe fix I'd love to see this in 0.9.1
more people are starting to see this. changing milestone.
Target Milestone: mozilla0.9.2 → mozilla0.9.1
I am on it. I don't now what appends but at least I can reproduce it all the time.
Whiteboard: [nsbeta1+] → [nsbeta1+] Working on it...
Any chance the necko fix that got checked in to fix this the last time this occurred got broken?
I saw this with 5/25 04 build just attempting to send a message with a simple text file attached.
Using the attached message (the one with a bugzilla query), I can reply to it if I remove the very long link at the beginning of the message. Do we have again a problem with long line in smtp??? mscott, any idea?
I did two smtp logs, one when the message get sorrectly sent, the second on when it stall. I compared them and here is the difference: when message sent correctly: [snap...] 0[99aa87c]: SMTP entering state: 0 0[99aa87c]: SMTP Response: 354 Ok Send data ending with <CRLF>.<CRLF> 0[99aa87c]: SMTP entering state: 8 0[99aa87c]: SMTP entering state: 9 0[99aa87c]: SMTP Send: . [snap...] When send stall (and before it timeout): 0[99aa88c]: SMTP entering state: 0 0[99aa88c]: SMTP Response: 354 Ok Send data ending with <CRLF>.<CRLF> 0[99aa88c]: SMTP entering state: 8 0[99aa88c]: SMTP entering state: 9 For some reason, we never send the final "." to tell the server that's the end of the message.
Ok, I did some debugging and here is what appends: Everything seems ok until we start streaming the message data itself. nsMsgFilePostHelper::OnDataAvailable -We detect a "\n." in the stream -We try to send data up to the "\n." but not everything get written therefore we call SuspendPostFileRead. Then nsMsgProtocolStreamProvoder::OnDataWritable get called which cause us to resume the write opeartion. We write the remaining data up to the "\n.", then write an extra "." then try to write the remaining data after the "\n." but again we cannot write all of it. Therefore we have to suspend the stream again but this time, nsMsgProtocolStreamProvoder::OnDataWritable never get called back until we timeout! I think this is more a bug for mscott. Scott, can you take care of this one?
sure thing....looks like me...thanks for the detective work JF.
Assignee: ducarroz → mscott
Status: ASSIGNED → NEW
Looks like the write is suspended but we are doing nothing to help it to unblock it.
ok, I have more info: in nsMsgProtocolStreamProvider::OnDataWritable, First we test is we have something to write in the pipe, if yes, we write it then we process suspended read data. Else, we just return NS_BASE_STREAMWOULD_BLOCK. But in some case, when we process the suspended read data, the write doesn't write and return o byte written. Then next time we reach OnDataWritable, we will just return NS_BASE_STREAM_WOULD_BLOCK because there is nothing in the output pipe! At this point, both read and write are suspended!!!
Whiteboard: [nsbeta1+] Working on it... → [nsbeta1+]
*** Bug 83144 has been marked as a duplicate of this bug. ***
cc'ing myself as I am not the owner anymore...
Whiteboard: [nsbeta1+] → [nsbeta1+],eta = unknown
Whiteboard: [nsbeta1+],eta = unknown → wanted for 0.9.1 [nsbeta1+],eta = unknown
any updates on this one?
I think I ran into this when Lisa did a send page of bug 69203 to me with a question. I click Reply and typed the answer to the question and Sending never finished, 5 minutes later I get a time out error. Just another scenario.
Attached patch proposed fix. (deleted) — Splinter Review
Here's the fix. I found several other problems that I think could cause us to not send but fixes for those problems weren't required for this fix. So I'll just check those into the tip and not the .9.1 branch. This fix is for the branch. We'll need to QA SMTP send pretty heavily after this change but I'm pretty sure it won't cause a regression.
Status: NEW → ASSIGNED
Whiteboard: wanted for 0.9.1 [nsbeta1+],eta = unknown → wanted for 0.9.1 [nsbeta1+], fix in hand r=?, sr=?
Here's what I fixed..... for some reason mSuspendedReadBytes (# of bytes we still have to read out of our input stream before we can unblock the input stream and start reading more bytes from the post file again), was getting out of synch with the actual # of bytes available to read from the input stream. In particular, for this message, it was getting larger than the total # of bytes available to be read in the input stream. I still have to figure out why that is happening but this hack covers it up by resetting mSuspendedReadBytes to the # of bytes available when we are trying to unblock the input stream. I have several other fixes for this code that could cause problems (but no test cases) so those will go into the tip.
sr=bienvenu - I wonder if this or something similar was causing some weird file channel problems I was seeing a while ago with copying lots of local messages.
a= asa@mozilla.org for chekin to 0.9.1
fix checked in to the 0.9.1 branch only for mscott.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Sean, this was only checked in to the trunk, never the 0.9.1 branch as far as I can see.
I downloaded 2001-06-03-10 trunk build and just did a quick test and replied to the above attached message which was failing to send and I was able to send. Just a fyi.. Still testing...
To verify this bug on each platform I ran a few different send test cases. My outgoing SMTP server SSL was checked to never and so was my SSL for sending. -Replied, forwarded the message attached below -Send bug page 69203 stated in esther's comments and tested reply, reply, forward (inline, as attachment) -send pages (netscape home page, aol web page) -reply to the above web pages -Replied to replied message above -forward the above replied message The above test cases were run to verify send did not fail. Trunk Builds: 2001-06-05-06win98 2001-06-05-04mac 2001-06-05-06linux Branch builds: 2001-06-05-09win98 2001-06-05-04linux 2001-06-05-03mac
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: