hang when displaying image attachments

VERIFIED FIXED in mozilla1.3beta


MailNews Core
Networking: NNTP
15 years ago
9 years ago


(Reporter: Tomi Leppikangas, Assigned: Darin Fisher)


({hang, regression})

hang, regression

Firefox Tracking Flags

(Not tracked)



(2 attachments)

52.66 KB, text/plain
1.11 KB, patch
(not reading, please use seth@sspitzer.org instead)
: review+
(not reading, please use seth@sspitzer.org instead)
: superreview+
Details | Diff | Splinter Review


15 years ago
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:

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

15 years ago
Created attachment 112885 [details]
Last 1000 lines from nspr logfile with NSPR_LOG_MODULES=all:5


15 years ago
Severity: normal → critical

Comment 2

15 years ago
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

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

Comment 4

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

-> me
Assignee: sspitzer → darin
Priority: -- → P1
Target Milestone: --- → mozilla1.3beta

Comment 5

15 years ago
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%
<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

15 years ago
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

15 years ago
possibly related to bug 190946.

Comment 8

15 years ago
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

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

Comment 10

15 years ago
Created attachment 112916 [details] [diff] [review]
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

15 years ago
Comment on attachment 112916 [details] [diff] [review]
v1 patch

seth: can you suggest another reviewer for this patch?	thx!
Attachment #112916 - Flags: review?(sspitzer)


15 years ago
Flags: blocking1.3b?
Keywords: regression
Comment on attachment 112916 [details] [diff] [review]
v1 patch

Attachment #112916 - Flags: superreview+
Attachment #112916 - Flags: review?(sspitzer)
Attachment #112916 - Flags: review+
Comment on attachment 112916 [details] [diff] [review]
v1 patch

something for 1.3 beta
Attachment #112916 - Flags: approval1.3b?

Comment 14

15 years ago
Comment on attachment 112916 [details] [diff] [review]
v1 patch

a=asa (on behalf of drivers) for checkin to 1.3beta.
Attachment #112916 - Flags: approval1.3b? → approval1.3b+


15 years ago
Flags: blocking1.3b?

Comment 15

15 years ago
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 16

15 years ago
Verified as fixed in build 2003013005
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.