190988 - hang when displaying image attachments

Status: VERIFIED FIXED

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

Description

[Tomi Leppikangas]

Mozilla hang when displaying image attachments. Small attachments seems
to work, but most images just hangs.

2003011708 is last nightly that works, all after that hangs.

Header seems to load ok (window caption is updated) but then hangs.

Steps to reproduce:
1. start mailnews
2. subscribe to some group with pictures
3. view some images

Actual results:
 Hang

Expected:
  Image viewed


gdb backtrace when hang:

#0  0x420293d5 in sigsuspend () from /lib/i686/libc.so.6
#1  0x4012f609 in __pthread_wait_for_restart_signal () from 
    /lib/i686/libpthread.so.0
#2  0x4012beec in pthread_cond_wait () from /lib/i686/libpthread.so.0
#3  0x400fc3f8 in PR_WaitCondVar (cvar=0x8837320, timeout=4294967295)
    at ../../../../../nsprpub/pr/src/pthreads/ptsynch.c:389
#4  0x400fcbaf in PR_Wait (mon=0x879d118, timeout=4294967295)
    at ../../../../../nsprpub/pr/src/pthreads/ptsynch.c:567
#5  0x40504549 in nsAutoMonitor::Wait (this=0xbfffef50, interval=4294967295)
    at ../../dist/include/xpcom/nsAutoLock.h:278
#6  0x40502670 in nsPipeOutputStream::Wait (this=0x885fb90)
    at ../../../xpcom/io/nsPipe3.cpp:917
#7  0x40502b3f in nsPipeOutputStream::WriteSegments (this=0x885fb90, 
    reader=0x40502c54 <nsReadFromRawBuffer(nsIOutputStream *, void *, char *,
    unsigned int, unsigned int, unsigned int *)>, closure=0x877fe38, count=58, 
    writeCount=0xbfffeffc) at ../../../xpcom/io/nsPipe3.cpp:1029
#8  0x40502ccb in nsPipeOutputStream::Write (this=0x885fb90, 
    from Buf=0x877fe38 
    "M4T1(*ES7J@.B:5ZH`@2Q!U3()?:7]B2H['9]'2AU)D2#HUE64N!]+ZJ*;-[]",
    bufLen=61, writeCount=0xbfffeffc) at ../../../xpcom/io/nsPipe3.cpp:1088
#9  0x4560b6bc in nsNNTPProtocol::DisplayArticle (this=0x87ce728, 
    inputStream=0x89188bc, length=16384)
    at ../../../../mailnews/news/src/nsNNTPProtocol.cpp:2557
#10 0x4560b8e3 in nsNNTPProtocol::ReadArticle (this=0x87ce728, 
    inputStream=0x89188bc, length=16384)
    at ../../../../mailnews/news/src/nsNNTPProtocol.cpp:2599
#11 0x45614ac9 in nsNNTPProtocol::ProcessProtocolState (this=0x87ce728, 
    url=0x88868ac, inputStream=0x89188bc, sourceOffset=41930, length=16384)
    at ../../../../mailnews/news/src/nsNNTPProtocol.cpp:5128
#12 0x431ee723 in nsMsgProtocol::OnDataAvailable (this=0x87ce734, 
    request=0x88be198, ctxt=0x88868a8, inStr=0x89188bc, sourceOffset=41930, 
    count=16384) at ../../../../mailnews/base/util/nsMsgProtocol.cpp:327
#13 0x40895212 in nsInputStreamPump::OnStateTransfer (this=0x88be198)
    at ../../../../netwerk/base/src/nsInputStreamPump.cpp:402
#14 0x40894e33 in nsInputStreamPump::OnInputStreamReady (this=0x88be198, 
    stream=0x89188bc) at ../../../../netwerk/base/src/nsInputStreamPump.cpp:317
#15 0x4050604d in nsInputStreamReadyEvent::EventHandler (plevent=0x8308a08)
    at ../../../xpcom/io/nsStreamUtils.cpp:101
#16 0x4052b9f0 in PL_HandleEvent (self=0x8308a08)
    at ../../../xpcom/threads/plevent.c:663
#17 0x4052b805 in PL_ProcessPendingEvents (self=0x8123cd8)
    at ../../../xpcom/threads/plevent.c:593
#18 0x4052db06 in nsEventQueueImpl::ProcessPendingEvents (this=0x8123c90)
    at ../../../xpcom/threads/nsEventQueue.cpp:387
#19 0x4154cc50 in event_processor_callback (data=0x8123c90, source=6, 
    condition=GDK_INPUT_READ) at ../../../../widget/src/gtk/nsAppShell.cpp:198
#20 0x4154c6e3 in our_gdk_io_invoke (source=0x82ba7b0, condition=G_IO_IN, 
    data=0x82c7988) at ../../../../widget/src/gtk/nsAppShell.cpp:77
#21 0x402b4f9e in g_io_unix_dispatch () from /usr/lib/libglib-1.2.so.0
#22 0x402b6773 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#23 0x402b6d39 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#24 0x402b6eec in g_main_run () from /usr/lib/libglib-1.2.so.0
#25 0x401d22e3 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#26 0x4154d1d9 in nsAppShell::Run (this=0x8188368)
    at ../../../../widget/src/gtk/nsAppShell.cpp:346
#27 0x414fba8d in nsAppShellService::Run (this=0x8180aa8)
    at ../../../../xpfe/appshell/src/nsAppShellService.cpp:479
#28 0x08066819 in main1 (argc=2, argv=0xbffff714, nativeApp=0x8103380)
    at ../../../xpfe/bootstrap/nsAppRunner.cpp:1298
#29 0x080673d7 in main (argc=2, argv=0xbffff714)
    at ../../../xpfe/bootstrap/nsAppRunner.cpp:1668
#30 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6

Comment 1

[Tomi Leppikangas]

Attachment: Last 1000 lines from nspr logfile with NSPR_LOG_MODULES=all:5

Comment 2

[Ninoschka Baca]

What size are the images? What type of images (gif, jpg etc...)? Could you
attach one of the images or suggest a newsgroup?

Comment 3

[Darin Fisher]

could this be a duplicate of bug 189689?  what is the most recent trunk build
you have tested?

Comment 4

[Darin Fisher]

ok, Tomi says he can repro this using today's trunk bits.

-> me

Comment 5

[Darin Fisher]

comments from Tomi:

<imoT> darin: bug #190988 might be regression from async stream landing, at
least it started 17.1
<darin> imoT: ok, thx
<darin> imoT: looks like a duplicate of a bug that has already been fixed
<imoT> darin: when it is fixed? i tryed with todays nightly
<darin> imoT: so you can repro with today's trunk build?
<imoT> darin: yes
<darin> imoT: hmm.. ok
<darin> imoT: what news message were you viewing when it happened?  is it 100%
reproducible?
<imoT> darin: this is 2003012805 build
<darin> imoT: ok
<imoT> darin: eg some pictured from alt.binaries.* groups, small images view ok,
bigger hang allways
<darin> imoT: ok
<darin> imoT: thx
<imoT> darin: 2003011708 works ok
<darin> imoT: ok

Comment 6

[Tomi Leppikangas]

Actually it looks like it doesnt have to be image, any long posting
would hang. Hard to say how long it have to be, our news server have
1MB limit, so its smaller that that.

Comment 7

[Darin Fisher]

possibly related to bug 190946.

Comment 8

[Tomi Leppikangas]

Yes i hit that bug #190946 also sometimes.

Here is steps that reproduces this bug:
1. dd if=/dev/zero of=/tmp/60k bs=1024 count=60
2. post message and attach that file
3. try to read just posted article

in news server it looks like this:
-rw-rw-r--   1 news     news       84156 Jan 29 00:51 spool/articles/test/9784

Comment 9

[Darin Fisher]

ok, i have a patch that fixes both bugs.  however, they are actually distinct bugs.

Comment 10

[Darin Fisher]

Attachment: v1 patch

the display pipe should not have a limited size.  it is a "blocking" pipe and
sure enough it was getting blocked, waiting on a monitor, once full.  i'm not
sure how this ever worked before bug 176919, but this seems like a decent fix.

Comment 11

[Darin Fisher]

Comment on attachment 112916 [details] [diff] [review]
v1 patch

seth: can you suggest another reviewer for this patch?	thx!

Comment 12

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

Comment on attachment 112916 [details] [diff] [review]
v1 patch

r/sr=sspitzer

Comment 13

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

Comment on attachment 112916 [details] [diff] [review]
v1 patch

something for 1.3 beta

Comment 14

[Asa Dotzler [:asa]]

Comment on attachment 112916 [details] [diff] [review]
v1 patch

a=asa (on behalf of drivers) for checkin to 1.3beta.

Comment 15

[Darin Fisher]

fixed-on-trunk

Comment 16

[Tomi Leppikangas]

Verified as fixed in build 2003013005