52.66 KB, text/plain
1.11 KB, patch
(not reading, please use email@example.com instead): review+
(not reading, please use firstname.lastname@example.org instead): superreview+
|Details | Diff | Splinter Review|
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
What size are the images? What type of images (gif, jpg etc...)? Could you attach one of the images or suggest a newsgroup?
could this be a duplicate of bug 189689? what is the most recent trunk build you have tested?
ok, Tomi says he can repro this using today's trunk bits. -> me
Assignee: sspitzer → darin
Priority: -- → P1
Target Milestone: --- → mozilla1.3beta
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
Status: NEW → ASSIGNED
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.
possibly related to bug 190946.
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
ok, i have a patch that fixes both bugs. however, they are actually distinct bugs.
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 on attachment 112916 [details] [diff] [review] v1 patch seth: can you suggest another reviewer for this patch? thx!
Comment on attachment 112916 [details] [diff] [review] v1 patch r/sr=sspitzer
Comment on attachment 112916 [details] [diff] [review] v1 patch something for 1.3 beta
Attachment #112916 - Flags: approval1.3b?
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+
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
Verified as fixed in build 2003013005
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.