Closed Bug 14680 Opened 26 years ago Closed 26 years ago

Regression: message with embedded image freeze Messenger 5.0

Categories

(MailNews Core :: MIME, defect, P3)

Product:
MailNews Core
Component:
MIME
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: fenella, Assigned: mscott)

References

Details

Linux (1999-09-22-08 M11) Win_nt (1999-09-22-09 M11) Mac (1999-09-22-08 M11) Steps: 1. From Messenger, compose a message 2. Enter all the fields in the header and some text in the Body 3. Select File|Attach File, select a gif file (or jpeg file) 3a Or select the Attach button and select a gif file from the local drive 4. Send the message 5. View the message from 5.0. Actual result: It does not display the image file. But view the message from Nova 4.7, it is there. Expected result: the attached image file should be displayed, just like Nova This occurs on Mac and Win_nt 4.0 as well
QA Contact: lchiang → pmock
Move milestone stoppers to M10
Status: NEW → ASSIGNED
Component: Composition → MIME
It's a mime parser problem, nothing to do with message composition.
I have sent a message from Nav 4.7 with an image in the middle of it (4K). When I try to display the message with Messenger 5.0 on Mac or Windows, the application freeze! It's the same for all other messages with an image in my mailbox.
Severity: normal → blocker
Summary: Regression: Attached image does not display on 5.0 → Regression: message with embedded image freeze Messenger 5.0
Update summary of change the severity to blocker
_PR_WaitCondVar(PRThread * 0x010a2790, PRCondVar * 0x010a2330, PRLock * 0x010a23e0, unsigned int 0xffffffff) line 175 + 23 bytes PR_Wait(PRMonitor * 0x010a2490, unsigned int 0xffffffff) line 155 + 29 bytes PR_CWait(void * 0x032b3160, unsigned int 0xffffffff) line 354 + 13 bytes nsAutoCMonitor::Wait(unsigned int 0xffffffff) line 242 + 16 bytes nsPipe::nsPipeInputStream::Fill() line 434 + 10 bytes nsPipe::nsPipeInputStream::ReadSegments(nsPipe::nsPipeInputStream * const 0x032b3168, unsigned int (void *, const char *, unsigned int, unsigned int, unsigned int *)* 0x10032760 nsWriteToRawBuffer(void *, const char *, unsigned int, unsigned int, unsigned int *), void * 0x012056e8, unsigned int 0x00000800, unsigned int * 0x0012fc84) line 364 + 8 bytes nsPipe::nsPipeInputStream::Read(nsPipe::nsPipeInputStream * const 0x032b3168, char * 0x012056e8, unsigned int 0x00000800, unsigned int * 0x0012fc84) line 463 ImageConsumer::OnDataAvailable(ImageConsumer * const 0x032900a0, nsIChannel * 0x032b6f20, nsISupports * 0x032908e4, nsIInputStream * 0x032b3168, unsigned int 0x00000000, unsigned int 0x00000174) line 277 + 27 bytes nsMimeBaseEmitter::Complete(nsMimeBaseEmitter * const 0x032b31e0) line 140 nsStreamConverter::OnStopRequest(nsStreamConverter * const 0x032b49d0, nsIChannel * 0x032904b4, nsISupports * 0x00000000, unsigned int 0x00000000, const unsigned short * 0x00000000) line 700 nsChannelListener::OnStopRequest(nsChannelListener * const 0x03290060, nsIChannel * 0x032904b4, nsISupports * 0x00000000, unsigned int 0x00000000, const unsigned short * 0x00000000) line 1590 + 42 bytes nsMsgProtocol::OnStopRequest(nsMsgProtocol * const 0x032904b0, nsIChannel * 0x03291c10, nsISupports * 0x032908e0, unsigned int 0x00000000, const unsigned short * 0x00000000) line 192 + 74 bytes nsMailboxProtocol::OnStopRequest(nsMailboxProtocol * const 0x032904b0, nsIChannel * 0x03291c10, nsISupports * 0x032908e0, unsigned int 0x00000000, const unsigned short * 0x00000000) line 174 nsFileChannel::OnStopRequest(nsFileChannel * const 0x03291c14, nsIChannel * 0x03291b80, nsISupports * 0x032908e0, unsigned int 0x00000000, const unsigned short * 0x00000000) line 466 + 45 bytes nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x032916e0) line 283 nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x03291490) line 152 + 12 bytes PL_HandleEvent(PLEvent * 0x03291490) line 541 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x0110e500) line 500 + 9 bytes _md_EventReceiverProc(HWND__ * 0x0048038e, unsigned int 0x0000c0dd, unsigned int 0x00000000, long 0x0110e500) line 970 + 9 bytes USER32! 77e71820() 0110e500()
FYI: I freeze either with JPG of GIFF image under POP3.
*** Bug 14728 has been marked as a duplicate of this bug. ***
Bug 14728 is the Bitmap version of this bug. Add Warren in cc for his advice and reassign it to jefft
Assignee: ducarroz → jefft
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Warren, I'm not sure why the pipe is getting blocked, but looking at the code, the ODA code the mime stream converter is generating should have the exact number of bytes that are in the stream. (I was thinking this may be a dup of the bug where we block if you ask for more bytes than bytes already in the stream). Here's the surrounding code snippet in nsMimeBaseEmitter::Complete which basically flushes the converted data to the consumer: mInputStream->Available(&bytesInStream); mOutListener->OnDataAvailable(mChannel, mURL, mInputStream, 0, bytesInStream); Given the fact that I'm passing in the # of available bytes for reading, I can't understand why the pipe would get blocked trying to read in the same number of bytes. Unless nsIInputStream::Available was returning the wrong number? Any ideas? Note, this is an M10 stopper.
Oh I see the problem. It is in fact the problem that the pipe blocks if you try to read more bytes than you actually have available. The problem is in: ImageConsumer::OnDataAvailable It has a variable max_read which is set to the max # of byts IT can handle (i.e. it's buffer size). It's ignoring the length paramater passed in to ODA and is usinng max_read instead. I bet max_read is greater than the length we are passing in on the ODA available call. And the pipe is blocking. This is a known necko bug. I bet we can fix ImageConsumer::OnDataAvailable to work around it though. It should only take a couple lines. I can fix it.
Scott, I was going to change the streams passed in OnDataAvailable to be non-blocking. That means that your code will have to check for the NS_BASE_STREAM_WOULD_BLOCK error code after calling Read. That will prevent blocking in Fill, but might cause you other problems if you don't notice the error. Let me know what you think. Warren
Re-assigning to me... Warren, it turns out that the image code was already checking to see if Read returned NS_BASE_STREAM_WOULD_BLOCK. But the mime converter pipe I created was never setting it's stream to be non-blocking. I believe I just have to set the streams to non-blocking like you do for the socket transport's pipe. Jean-Francois is trying my patch out for this right now.
Assignee: jefft → mscott
Status: ASSIGNED → NEW
Re-assigning to me. The fix does indeed work. I'm going to ask Jean-Francois to check this in for me. If someone asks, he's reviewed the change and I've talked about the change of making the stream non blocking to Warren and he's agreed that it's the right thing to do as well.
Will this also fix the nsPipe::nsOutputStream problem?
If you are thinking about the blockage when flushing the output stream, the anwser is yes but in the case where we freeze when quoting large message (bug number ?), that doesn't fix the loose of date (body truncated at 32K).
Yes, that's what I meant. Thanks.
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Fixed and checked in (M10 BRANCH only)
I checked this into the tip too.
Linux (1999-10-01-18 M10) This problem is fixed on Linux in the M10 build.
Status: RESOLVED → VERIFIED
Linux (1999-10-13-08 m11) commercial Win32 (1999-10-13-09 m11) commercial Mac (1999-10-13-08 m11) commercial The problem that Message with embedded image freeze messenger has been fixed. However, I cannot display gif or jpeg image file using today's Win_nt build. Linux and Mac work fine though. I am going to open a parity bug for win32, bug 16313.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.