433888 - crash when news server connection times out a second time [@ nsStreamListenerTee::Release] -[@ nsNNTPProtocol::CleanupAfterRunningUrl]

Status: RESOLVED WORKSFORME

(MailNews Core :: Networking: NNTP, defect)

Description

[Bradley Baetz (:bbaetz)]

Attachment: backtrace

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

Comment 1

[Bradley Baetz (:bbaetz)]

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 ()

Comment 2

[Bradley Baetz (:bbaetz)]

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

[Joshua Cranmer [:jcranmer]]

xref bug 478469. Probably the same bug. (Crashing in mailnews/news -> Networking: News component).

Comment 4

[Wayne Mery (:wsmwk)]

bug bug 478469 has more "stuff" and progress, so setting dependency

Comment 5

[Wayne Mery (:wsmwk)]

Bradley has said "I haven't seen this on F11."
So closing WFM