14682 - Message Compose Window Hangs when Forwarding Large Message

Status: VERIFIED DUPLICATE of bug 14612

(MailNews Core :: Composition, defect, P3)

Description

[sol]

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.

Comment 1

[lchiang]

May be similar to bug 14612

Comment 2

[Jean-Francois Ducarroz]

I am not pretty sure is related to bug 14612! I am investigating...

Comment 3

[Jean-Francois Ducarroz]

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?

Comment 4

[Jean-Francois Ducarroz]

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...

Comment 5

[Scott MacGregor]

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!

Comment 6

[Jean-Francois Ducarroz]

no problem, reassign...

Comment 7

[Scott MacGregor]

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 ***

Comment 8

[fenella]

Bug 14612 has been verified. Mark this verified too.