Closed
Bug 82643
Opened 23 years ago
Closed 23 years ago
Replying to a message fails
Categories
(MailNews Core :: Composition, defect, P1)
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)
(deleted),
text/plain
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•23 years ago
|
||
Comment 2•23 years ago
|
||
nominating nsbeta1. I message we cannot send is a dataloss
Reporter | ||
Updated•23 years ago
|
Priority: -- → P1
Whiteboard: [nsbeta1+]
Target Milestone: --- → mozilla0.9.2
Reporter | ||
Comment 3•23 years ago
|
||
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
Reporter | ||
Comment 4•23 years ago
|
||
more people are starting to see this. changing milestone.
Target Milestone: mozilla0.9.2 → mozilla0.9.1
Comment 5•23 years ago
|
||
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...
Reporter | ||
Comment 6•23 years ago
|
||
Any chance the necko fix that got checked in to fix this the last time this
occurred got broken?
Comment 7•23 years ago
|
||
I saw this with 5/25 04 build just attempting to send a message with a simple
text file attached.
Comment 8•23 years ago
|
||
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?
Comment 9•23 years ago
|
||
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.
Comment 10•23 years ago
|
||
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?
Assignee | ||
Comment 11•23 years ago
|
||
sure thing....looks like me...thanks for the detective work JF.
Assignee: ducarroz → mscott
Status: ASSIGNED → NEW
Comment 12•23 years ago
|
||
Looks like the write is suspended but we are doing nothing to help it to unblock it.
Comment 13•23 years ago
|
||
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+]
Comment 14•23 years ago
|
||
*** Bug 83144 has been marked as a duplicate of this bug. ***
Comment 15•23 years ago
|
||
cc'ing myself as I am not the owner anymore...
Reporter | ||
Updated•23 years ago
|
Whiteboard: [nsbeta1+] → [nsbeta1+],eta = unknown
Updated•23 years ago
|
Whiteboard: [nsbeta1+],eta = unknown → wanted for 0.9.1 [nsbeta1+],eta = unknown
Comment 16•23 years ago
|
||
any updates on this one?
Comment 17•23 years ago
|
||
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.
Assignee | ||
Comment 18•23 years ago
|
||
Assignee | ||
Comment 19•23 years ago
|
||
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
Assignee | ||
Updated•23 years ago
|
Whiteboard: wanted for 0.9.1 [nsbeta1+],eta = unknown → wanted for 0.9.1 [nsbeta1+], fix in hand r=?, sr=?
Assignee | ||
Comment 20•23 years ago
|
||
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.
Comment 21•23 years ago
|
||
r=sspitzer
Comment 22•23 years ago
|
||
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.
Comment 23•23 years ago
|
||
a= asa@mozilla.org for chekin to 0.9.1
Comment 24•23 years ago
|
||
fix checked in to the 0.9.1 branch only for mscott.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 25•23 years ago
|
||
Sean, this was only checked in to the trunk, never the 0.9.1 branch as far as I
can see.
Comment 26•23 years ago
|
||
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...
Comment 27•23 years ago
|
||
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
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•