Closed Bug 14682 Opened 21 years ago Closed 21 years ago
Message Compose Window Hangs when Forwarding Large Message
Message Compose Window hangs when forwarding a large message. Build ID: 1999092208 System: P166 32 Mb RAM Win95 Message size: 48Kb When forwarding a message from an IMAP account, the compose window hangs. Steps to reproduce: 1. Launch apprunner 2. Open mail (Tasks | Messenger) 3. Open a large IMAP inbox (1600 messages) 4. Select a large (48Kb) message 5. Press "Forward" Expected result: Compose window opens with selected message quoted Actual result: Compose window begins to draw, then hangs Note: I was able to load a 1Kb message into the compose window with no problems. Note2: The compose window also hung when forwarding the same message from a POP account.
May be similar to bug 14612
Severity: normal → critical
I am not pretty sure is related to bug 14612! I am investigating...
I make progress in my investigation: we are falling in a dead lock when trying to flush the output file buffer. Yes when you forward a message, we are writing the body to disk as we are using the html emitter (when you display the same message, we are using the XML emitter which one stream the data, that what it's working). Actually, I don't have any clue why we are blocked in nsPipe::nsPipeOutputStream::Flush(). Except that apparently appends only when the buffer is more than 32K and that Flush is waiting on a monitor! Who should unlock the monitor? which task?
In nsStreamConverter::Init(), we create a pipe without observer. By default a pipe is created as blocking. I think but I am not sure that when Flush block, it's waiting on the pipe observer function onFull() to unblock the situation. Do am I right? Anyway, I just set the pipe as non blocking after its creation in nsStreamConverter::Init() and now it almost works! I say almost because the forwarded or replied message is truncated at 32K? But at least we don't freeze anymore. I am looking know to understand why it's truncated...
Sorry for not responding to this bug earlier. I know what the problem here is too. The pipe used between the converter and layout which is displaying the message is 32K. We are flooding the pipe and not giving layout a chance to read from the pipe. The pipe only holds 32K and is blocking once we try to pump more into it. I have to fix the same problem for sending messages greater than 32K too! Jean-Francois, why don't you re-assign this to me. Sorry for making you spend cycles debugging this by not responding sooner!
no problem, reassign...
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
It turns out this is a necko bug involving writing into a pipe more bytes than the size of the pipe. Things block when flushing the stream. I've already assigned a similar bug to Warren. I'm going to mark this as a duplicate of that bug. *** This bug has been marked as a duplicate of 14612 ***
Bug 14612 has been verified. Mark this verified too.
You need to log in before you can comment on or make changes to this bug.