92637 - Hang / crash when double clicking on jpg attachments in news

Status: VERIFIED FIXED

(MailNews Core :: Networking: NNTP, defect, P1)

Description

[Brian Nesse (gone)]

I was reading newsgroups when I came across a messsage posted to the newsgroup
with 2 attached jpg images (custom.jpg and ns61-1.jpg). Double clicking on
either attachment attempts to open the jpg image in a browser window and hangs
mozilla.

Comment 1

[Brian Nesse (gone)]

Forgot to mention... this is in the Mozilla 0.9.2/6.1 RTM candidate bits built
this morning.

Comment 2

[lchiang]

Which news posting were you reading so we can try to reproduce with the exact
.jpg images.

We'll try with some other jpg images now.

Comment 3

[Brian Nesse (gone)]

It's on an internal server, not for public consumption :) I'll email you the info.

Comment 4

[Ninoschka Baca]

Branch build 2001-07-26-21: Mac 9.04
A basic test is ok. I created a message, attched two jpg files, sent/received
the message and I am able to view the jpg files without a problem. I also posted
the message to netscape.net and it appears ok, without a hang. We'll see what
extra information Brian can supply.

Comment 5

[lchiang]

nbaca and seth - I'll forward you Brian's email to me re: the server to see this
problem on.

Comment 6

[[e-mail] (gone - use [e-mail] instead)]

I'm hanging with just a test of the Condit picture from CNN (note that I have
quicktime configured as the problem for this filetype).  It's not exclusive to
double-clicking, either.  Just context-clicking on the attachment and then
choosing, "Open" hangs my system.

Comment 7

[[e-mail] (gone - use [e-mail] instead)]

that should be "configured as the program" (re: quicktime).

Comment 8

[(not reading, please use [e-mail] instead)]

wait, why aren't we handling the .jpg documents?  mozilla can display jpg.

Comment 9

[Ninoschka Baca]

If I open the attachment with my mail account first and then open it from the
news account then it does not hang. This may explain why it was working for me.

More details:
I created a message, attached 2 jpg files and sent it to my mail account and
netscape.test. If I open the images (double click or context/Open) in mail then
its ok. Then if I open the same files from the news account then its ok. 

After an exit/restart if I go straight to mail and try to double click or open
the attachment then it hangs. 

Comment 10

[[e-mail] (gone - use [e-mail] instead)]

We've all seen this on the 3 platforms, so Plat/OS --> All.

Comment 11

[[e-mail] (gone - use [e-mail] instead)]

Attachment: StdLog (during the hang)

Comment 12

[lchiang]

Is the hang only when opening in News?  If so, pls adjust the summary.

Comment 13

[Sheela Ravindran]

Actually, what ninoschka meant in her last paragraph was,
After an exit/restart if I go straight to news and try to double click or open
the attachment then it hangs. 

Comment 14

[Sheela Ravindran]

changed the summary as per nbaca's comments

Comment 15

[[e-mail] (gone - use [e-mail] instead)]

moving component from mail window front end --> networking - news 

Comment 16

[(not reading, please use [e-mail] instead)]

that macs bugs stack trace is similar to what nbaca & I saw on her machine.

Comment 17

[[e-mail] (gone - use [e-mail] instead)]

Attachment: Stack trace TB33532874

Comment 18

[(not reading, please use [e-mail] instead)]

on win2k, I sometimes get this crash:

memcpy(unsigned char * 0x04ec04c0, unsigned char * 0xdddddde1, unsigned long
0x00002000) line 171
nsCRT::memcpy(void * 0x04ec04c0, const void * 0xdddddde1, unsigned int
0x00002000) line 103 + 17 bytes
nsWriteToBuffer(nsIInputStream * 0x05951448, void * 0x04ec04c0, const char *
0xdddddde1, unsigned int 0x00000000, unsigned int 0x00002000, unsigned int *
0x0012f650) line 49 + 21 bytes
nsStorageTransport::nsReadRequest::ReadSegments(nsStorageTransport::nsReadRequest
* const 0x05951448, unsigned int (nsIInputStream *, void *, const char *,
unsigned int, unsigned int, unsigned int *)* 0x011f8f30
nsWriteToBuffer(nsIInputStream *, void *, const char *, unsigned int, unsigned
int, unsigned int *), void * 0x04ec04c0, unsigned int 0x00002000, unsigned int *
...) line 68
nsStorageTransport::nsReadRequest::Read(nsStorageTransport::nsReadRequest *
const 0x05951448, char * 0x04ec04c0, unsigned int 0x00002000, unsigned int *
0x0012faac) line 655
nsStreamConverter::OnDataAvailable(nsStreamConverter * const 0x05953b50,
nsIRequest * 0x0527ddc0, nsISupports * 0x00000000, nsIInputStream * 0x05951448,
unsigned int 0x00000000, unsigned int 0x00002000) line 878
nsNntpCacheStreamListener::OnDataAvailable(nsNntpCacheStreamListener * const
0x05953ad0, nsIRequest * 0x05951440, nsISupports * 0x00000000, nsIInputStream *
0x05951448, unsigned int 0x00000000, unsigned int 0x00002000) line 712 + 51 bytes
nsStorageTransport::nsReadRequest::OnDataAvailable(nsStorageTransport::nsReadRequest
* const 0x05951444, nsIRequest * 0x05951440, nsISupports * 0x00000000,
nsIInputStream * 0x05951448, unsigned int 0x00000000, unsigned int 0x00002000)
line 619 + 46 bytes
XPTC_InvokeByIndex(nsISupports * 0x05951444, unsigned int 0x00000005, unsigned
int 0x00000005, nsXPTCVariant * 0x058a1410) line 139
EventHandler(PLEvent * 0x058a1490) line 509 + 41 bytes
PL_HandleEvent(PLEvent * 0x058a1490) line 590 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00cf6900) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00a80212, unsigned int 0x0000c0e2, unsigned int
0x00000000, long 0x00cf6900) line 1071 + 9 bytes
USER32! 77e13eb0()
USER32! 77e1401a()
USER32! 77e192da()
nsAppShellService::Run(nsAppShellService * const 0x00d5be50) line 425
main1(int 0x00000003, char * * 0x00485ee0, nsISupports * 0x00000000) line 1290 +
32 bytes
main(int 0x00000003, char * * 0x00485ee0) line 1599 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e87903()

more info on the infinte loop coming next...

Comment 19

[(not reading, please use [e-mail] instead)]

on linux, I've gotten the infinite loop.

in nsStorageTransport::nsReadRequest::ReadSegments()

mTransferCount is 4294967295, aCount is 8192, count is 0;

while (aCount) {
  ...
  while(count) {
  }
}

so we loop because aCount is > 0, count is 0, and 
"rv = mTransport->GetReadSegment(mTransferOffset, &ptr, &count);" doesn't return
failure.

#0  nsStorageTransport::nsReadRequest::ReadSegments (this=0x8d74e98,
aWriter=0x408e8ba0 <nsWriteToBuffer(nsIInputStream *, void *, char const *,
unsigned int, unsigned int, unsigned int *)>, aClosure=0x862a7a8, aCount=8192,
aBytesRead=0xbffff150) at nsStorageTransport.cpp:676
#1  0x408ea5fb in nsStorageTransport::nsReadRequest::Read (this=0x8d74e98,
aBuf=0x862a7a8 "Ø\230Y@¸ï^\b", aCount=8192, aBytesRead=0xbffff150) at
nsStorageTransport.cpp:654
#2  0x420e3773 in nsStreamConverter::OnDataAvailable (this=0x8cf3b18,
request=0x8c921f0, ctxt=0x0, aIStream=0x8d74ea8, sourceOffset=0, aLength=8192)
at nsStreamConverter.cpp:876
#3  0x41ce3972 in nsNntpCacheStreamListener::OnDataAvailable (this=0x8d9eb18,
request=0x8d74ea0, aCtxt=0x0, aInStream=0x8d74ea8, aSourceOffset=0, aCount=8192)
at nsNNTPProtocol.cpp:712
#4  0x408ea4e2 in nsStorageTransport::nsReadRequest::OnDataAvailable
(this=0x8d74e98, aRequest=0x8d74ea0, aContext=0x0, aInput=0x8d74ea8, aOffset=0,
aCount=8192) at nsStorageTransport.cpp:619
#5  0x40198d91 in XPTC_InvokeByIndex (that=0x8d74ea4, methodIndex=5,
paramCount=5, params=0x8d9e968) at xptcinvoke_unixish_x86.cpp:138
#6  0x4017df03 in EventHandler (self=0x8c9c540) at nsProxyEvent.cpp:509
#7  0x40174612 in PL_HandleEvent (self=0x8c9c540) at plevent.c:590
#8  0x40174b59 in PL_ProcessEventsBeforeID (aSelf=0x80b0550, aID=23469) at
plevent.c:1256
#9  0x40a8483f in ?? () from
/builds/seth/seamonkey/mozilla/dist/bin/components/libwidget_gtk.so
#10 0x4013edfb in nsVoidArray::EnumerateForwards (this=0x8117428,
aFunc=0x40a84824, aData=0x5bad) at nsVoidArray.cpp:313
#11 0x40a84879 in ?? () from
/builds/seth/seamonkey/mozilla/dist/bin/components/libwidget_gtk.so
#12 0x40a8f8d2 in ?? () from
/builds/seth/seamonkey/mozilla/dist/bin/components/libwidget_gtk.so
#13 0x403a40fb in ?? () from /usr/lib/libgdk-1.2.so.0
#14 0x403d1a86 in ?? () from /usr/lib/libglib-1.2.so.0
#15 0x403d2041 in ?? () from /usr/lib/libglib-1.2.so.0
#16 0x403d21e1 in ?? () from /usr/lib/libglib-1.2.so.0
#17 0x402fb7a9 in ?? () from /usr/lib/libgtk-1.2.so.0
#18 0x40a845fc in ?? () from
/builds/seth/seamonkey/mozilla/dist/bin/components/libwidget_gtk.so
#19 0x407c2cf5 in ?? () from
/builds/seth/seamonkey/mozilla/dist/bin/components/libnsappshell.so
#20 0x8055783 in main1 (argc=1, argv=0xbffff9e4, nativeApp=0x0) at
nsAppRunner.cpp:1240
#21 0x805639d in main (argc=1, argv=0xbffff9e4) at nsAppRunner.cpp:1544
#22 0x404c8cb3 in ?? () from /lib/libc.so.6

darin, any suggestions on how to debug this?

Comment 20

[Brian Nesse (gone)]

mTransferCount == 4294967295 == 0xFFFFFFFF == -1. Probably indicates a special 
condition of some sort... error maybe? Just a thought...

Comment 21

[(not reading, please use [e-mail] instead)]

no, that's MAX_COUNT, the largest possible uint.

perhaps is this a problem with the news cache.  I'll contine debugging.

Comment 22

[[e-mail] (gone - use [e-mail] instead)]

QA --> stephend

Comment 23

[Brian Nesse (gone)]

Trying to reproduce this in Mozilla (debug) now, it is crashing for me. Stepping
through the code, it appears that the mTransport object (i.e.
mTransport->GetReadSegment() has been deleted. When I step into the
GetReadSegment call, "this" contains nothing but "0xEF" bytes.

Comment 24

[Brian Nesse (gone)]

With the caveat that I know absolutely nothing about this code...

 - mTransport is commented as being a weak reference in the header.
 - nsStorageTransport::nsReadRequest::GetTransport() ADDREF's mTransport.

I'd guess that someone isn't calling GetTransport when they're supposed to, thus
causing a premature release of mTransport.

Comment 25

[Darin Fisher]

Attachment: v1.0 fixes the problem

Comment 26

[Darin Fisher]

it turns out that there was never any code to handle the case when there is
nothing more to read.  so, i just added a check for |count==0| and that seems
to do the trick.

Comment 27

[Darin Fisher]

-> me

Comment 28

[Scott MacGregor]

excellent. sr=mscott.

Comment 29

[(not reading, please use [e-mail] instead)]

r=sspitzer

thanks darin.

Comment 30

[Brian Nesse (gone)]

So I applied this patch, but I crash before ever reaching it for the reasons
that I noted in my 2001-07-31 11:01 comment. The mTransport object is totally bogus.

Comment 31

[Darin Fisher]

fixed-on-trunk

Comment 32

[Darin Fisher]

bnesse: do you have a stack trace?

Comment 33

[Brian Nesse (gone)]

I'm actually looking at it in the debugger, but I will generate one and attach it.

Comment 34

[Brian Nesse (gone)]

Attachment: Stack crawl with addl info

Comment 35

[[e-mail] (gone - use [e-mail] instead)]

Okay, this is mostly working for me using builds:

Mac OS 9.1 - 2001-08-06-08
Windows 2K - 2001-08-06-03
RedHat 7.1 - 2001-08-06-08

Double-clicking the attachment or context-clicking it and choosing, "Open"
always opens the jpeg either in a new window (if no browser window is present
currently) or it opens it in the current browser window.

Side effects:  The 2nd or 3rd time you open this image, the throbber, cursor and
progress meter of either the new window or the message pane (where the news
posting is) will enter into a busy state (meteors failure?)  

If you close the new window that contains the image, the image will download,
but you'll enter that busy state.  If you leave that image in the navigator
window alone, return back to the newsgroup posting and open it, the navigator
window with the jpeg by itself will do the right thing and stop the progress
meter, busy cursor and throbber.

Comment 36

[[e-mail] (gone - use [e-mail] instead)]

Clarification:

If you close the new window that contains the image, the image will download,
but you'll enter that busy state.

Should read:

If you already have opened this image, close the window that holds it, and open
it up again (without there being a pre-exisiting navigator window with the
image) then you will enter the busy state.

Comment 37

[Darin Fisher]

can you open a new bug for this problem?  thx

Comment 38

[[e-mail] (gone - use [e-mail] instead)]

This is verified FIXED then, and I'll open a new bug for the side effects.

Comment 39

[Brian Nesse (gone)]

stephend, I would guess that what you are seeing as "side effects" are just
another manifestation of this problem.

I have debug builds on both Mac and win2k based on the 8/6 or later codebase
which both exibit this crash using my testcase.

I'm curious, what are you using for a testcase?

I'm going to attempt to find a test case which is not on an internal netscape
server.

Comment 40

[Brian Nesse (gone)]

I subscribed to the news group "alt.binaries.pictures.autos" (which contains a
bunch of postings with jpeg attachements.) My results...

Mac Debug:
 - reading through postings works as expected. Images appear correctly in
   message pane.
 - Double clicking on attachment item crashes.

Mac Opt (2001080704):
 - reading through postings works as expected. Images appear correctly in
   message pane.
 - Double clicking on attachment item opens in a new window. From this point
   Selecting any message previously read seems to work. Selecting any message
   still marked "unread" causes nothing to appear in the message pane. Even if
   it is a text only message.

Haven't tried win2k yet, but expect similar results.

Comment 41

[[e-mail] (gone - use [e-mail] instead)]

Brian, well, it's different behavior than was originally filed in this bug, and
has been filed as bug 94053, please add your comments there.  Thanks.