Closed
Bug 433888
Opened 16 years ago
Closed 14 years ago
crash when news server connection times out a second time [@ nsStreamListenerTee::Release] -[@ nsNNTPProtocol::CleanupAfterRunningUrl]
Categories
(MailNews Core :: Networking: NNTP, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: bbaetz, Unassigned)
References
Details
(Keywords: crash)
Crash Data
Attachments
(1 file)
10.25 KB,
text/plain
|
Details |
Reliably reproduced using thunderbird 2.0.0.14, both the fedora f8/f9 versions (x86_64) and the mozilla.org official builds (i386) If the remote end drops the connection (eg time out) a dialog box pops up, saying: 'Connection to news server news.gmane.org timed out' If I then have this happen a second time, I get the same dialog box, but then pressing OK crashes the server. Reproducable: Always to reproduce: - Add NNTP server news.gmane.org. Subscribe to a group, and select a message to read - Wait 10-20 minutes - connection will time out - click OK on the dialog box - Click on another message in the group (not one that it has cached) - Wait another 10-20 minutes - Click OK on the dialog box - See crash. Shouldn't crash (even better, should just transparently reconnect) Sometimes it doesn't time out - not sure whats triggering that; possibly something on the remote end? Talkback report submitted, but http://talkback-public.mozilla.org/ says that its about 25 hours lagged... The attached stacktrace is from the fedora f9 RPMs on x86_64. bug-buddy output, since it doesn't seem to crash under -g....
Reporter | ||
Comment 1•16 years ago
|
||
Stacktrace (from f9 RPMs): (gdb) bt #0 0x00007fc98002d280 in ?? () #1 0x00000000060d1d7d in ~nsStreamListenerTee (this=0x7fc97be8bb50) at ../../../dist/include/xpcom/nsCOMPtr.h:542 #2 0x00000000060d1a5d in nsStreamListenerTee::Release (this=0x7fc98002d298) at nsStreamListenerTee.cpp:40 #3 0x0000000000cb9a67 in nsNNTPProtocol::CleanupAfterRunningUrl ( this=0x7fc97c1ff710) at ../../../dist/include/xpcom/nsCOMPtr.h:713 #4 0x0000000000cb9b40 in nsNNTPProtocol::CloseSocket (this=0x7fc97c1ff710) at nsNNTPProtocol.cpp:5300 #5 0x0000000000ad4a0d in nsMsgProtocol::OnStopRequest (this=0x7fc97c1ff728, request=<value optimized out>, ctxt=0x6967e3a, aStatus=2218966160) at nsMsgProtocol.cpp:454 #6 0x0000000000cc065c in nsNNTPProtocol::OnStopRequest (this=0x7fc97c1ff710, request=0x7fc97f79d420, aContext=0x7fc9843cecd0, aStatus=2152398862) at nsNNTPProtocol.cpp:1233 #7 0x00000000060ba0a1 in nsInputStreamPump::OnStateStop (this=0x7fc97f79d420) at nsInputStreamPump.cpp:563 #8 0x00000000060ba2d7 in nsInputStreamPump::OnInputStreamReady ( this=0x7fc97f79d420, stream=0x0) at nsInputStreamPump.cpp:400 #9 0x00000039db85c5d6 in nsInputStreamReadyEvent::EventHandler ( plevent=<value optimized out>) at nsStreamUtils.cpp:120 #10 0x00000039db8739d0 in PL_HandleEvent (self=<value optimized out>) at plevent.c:688 #11 0x00000039db873be4 in PL_ProcessPendingEvents (self=<value optimized out>) at plevent.c:623 #12 0x00000039db875084 in nsEventQueueImpl::ProcessPendingEvents ( this=<value optimized out>) at nsEventQueue.cpp:448 #13 0x00007fc987b32ac6 in event_processor_callback ( source=<value optimized out>, condition=0, data=0x7fc98002d298) at nsAppShell.cpp:67 #14 0x00000039dd63749b in IA__g_main_context_dispatch ( context=<value optimized out>) at gmain.c:2009 #15 0x00000039dd63ac7d in g_main_context_iterate ( context=<value optimized out>, block=<value optimized out>, dispatch=<value optimized out>, self=<value optimized out>) at gmain.c:2642 #16 0x00000039dd63b1ad in IA__g_main_loop_run (loop=<value optimized out>) at gmain.c:2850 #17 0x00000039e2784888 in IA__gtk_main () at gtkmain.c:1163 #18 0x00007fc987b32f5a in nsAppShell::Run (this=0x7fc9873f3380) at nsAppShell.cpp:139 #19 0x00007fc9871c1ad4 in nsAppStartup::Run (this=0x7fc9873f3300) at nsAppStartup.cpp:151 #20 0x0000000000408a56 in XRE_main (argc=<value optimized out>, argv=<value optimized out>, aAppData=<value optimized out>) at nsAppRunner.cpp:2817 #21 0x00000039dbe1e32a in __libc_start_main () from /lib64/libc.so.6 #22 0x0000000000403949 in _start ()
Reporter | ||
Comment 2•16 years ago
|
||
And with NSPR logging for nntp, I get, just before this: 927070096[6e3f40]: (29e9e00) Next state: NNTP_READ_ARTICLE 927070096[6e3f40]: (29e9e00) Next state: NEWS_DONE 927070096[6e3f40]: (29e9e00) Next state: NEWS_FREE 927070096[6e3f40]: (29e9e00) CleanupAfterRunningUrl() 927070096[6e3f40]: (29e9e00) setting busy to 0 927070096[6e3f40]: (29e9e00) setting busy to 1 927070096[6e3f40]: (29e9e00) ParseURL 927070096[6e3f40]: (29e9e00) original message spec = news-message://news.gmane.org/gmane.network.nsp.cisco#51101 927070096[6e3f40]: (29e9e00) setting busy to 0 [New Thread 0x43fb2950 (LWP 7459)] Detaching after fork from child process 7460. 927070096[6e3f40]: (113e390) ClosingSocket() 927070096[6e3f40]: (113e390) CleanupAfterRunningUrl() Program received signal SIGSEGV, Segmentation fault.
Comment 3•15 years ago
|
||
xref bug 478469. Probably the same bug. (Crashing in mailnews/news -> Networking: News component).
Component: General → Networking: News
Product: Thunderbird → MailNews Core
QA Contact: general → networking.news
Version: 2.0 → 1.8 Branch
Comment 4•15 years ago
|
||
bug bug 478469 has more "stuff" and progress, so setting dependency
Depends on: 478469
Comment 5•14 years ago
|
||
Bradley has said "I haven't seen this on F11." So closing WFM
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Summary: crash when news server connection times out a second time → crash when news server connection times out a second time [@ nsStreamListenerTee::Release] -[@ nsNNTPProtocol::CleanupAfterRunningUrl]
Assignee | ||
Updated•13 years ago
|
Crash Signature: [@ nsStreamListenerTee::Release]
[@ nsNNTPProtocol::CleanupAfterRunningUrl]
You need to log in
before you can comment on or make changes to this bug.
Description
•