72317 - abort (on exit) if I send data on a socket that is closed?

Status: VERIFIED DUPLICATE of bug 72320

(MailNews Core :: Networking: NNTP, defect)

Description

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

the news code has a bug where it some times tries to send "ARTICLE " on the
socket on shutdown.

on the trunk, this causes us to abort.

#0  0x402e14e1 in __kill () from /lib/libc.so.6
#1  0x402551eb in raise (sig=6) at signals.c:64
#2  0x402e2868 in abort () at ../sysdeps/generic/abort.c:88
#3  0x40221945 in PR_Assert ()
   from /builds/seth/seamonkey/mozilla/dist/bin/libnspr4.so
#4  0x4021f0cf in _PR_InvalidInt ()
   from /builds/seth/seamonkey/mozilla/dist/bin/libnspr4.so
#5  0x4021f285 in PR_Write ()
   from /builds/seth/seamonkey/mozilla/dist/bin/libnspr4.so
#6  0x40ae29a5 in nsSocketBOS::Write (this=0x8fa2570, 
    aBuf=0x923a968 "ARTICLE >\r\n", aCount=11, aBytesWritten=0xbffff5f0)
    at nsSocketTransport.cpp:1922
#7  0x41b6cceb in nsMsgProtocol::SendData (this=0x871cc90, aURL=0x91f9d54, 
    dataBuffer=0x923a968 "ARTICLE >\r\n", aSuppressLogging=0)
    at nsMsgProtocol.cpp:218
#8  0x41ad389a in nsNNTPProtocol::SendData (this=0x871cc88, aURL=0x91f9d54, 
    dataBuffer=0x923a968 "ARTICLE >\r\n", aSuppressLogging=0)
    at nsNNTPProtocol.cpp:1365
#9  0x41ad5543 in nsNNTPProtocol::SendFirstNNTPCommand (this=0x871cc88, 
    url=0x871f34c) at nsNNTPProtocol.cpp:2059
#10 0x41ae102d in nsNNTPProtocol::ProcessProtocolState (this=0x871cc88, 
    url=0x871f34c, inputStream=0x870d978, sourceOffset=1605, length=5)
    at nsNNTPProtocol.cpp:4927
#11 0x41b6cd62 in nsMsgProtocol::OnDataAvailable (this=0x871cc90, 
    request=0x91ba7e0, ctxt=0x871f348, inStr=0x870d978, sourceOffset=1605, 
    count=5) at nsMsgProtocol.cpp:230
#12 0x40aed289 in nsOnDataAvailableEvent::HandleEvent (this=0x421068e8)
    at nsStreamListenerProxy.cpp:161
#13 0x40aeb879 in nsStreamObserverEvent::HandlePLEvent (aEvent=0x421068e8)
    at nsStreamObserverProxy.cpp:78
#14 0x400ed592 in PL_HandleEvent (self=0x421068e8) at plevent.c:586
#15 0x400ed429 in PL_ProcessPendingEvents (self=0x80a82a0) at plevent.c:516
#16 0x400ef1fc in nsEventQueueImpl::ProcessPendingEvents (this=0x80a8278)
    at nsEventQueue.cpp:361
#17 0x400ef27d in nsEventQueueImpl::ProcessPendingEvents (this=0x8dce000)
    at nsEventQueue.cpp:367
#18 0x400a67b5 in NS_ShutdownXPCOM (servMgr=0x0) at nsXPComInit.cpp:474
#19 0x8052f81 in main (argc=1, argv=0xbffff9b4) at nsAppRunner.cpp:1306

Comment 1

[David :Bienvenu]

Necko made some changes while we were on the branch.  You can try adding code
like the following after the socket is setup somewhere in the nsNNTPProtocol code.

    if (m_transport)
    {
      nsCOMPtr <nsISocketTransport> socket = do_QueryInterface(m_transport);
      if (socket)
        socket->SetReuseConnection(PR_TRUE);
    }

Comment 2

[Darin Fisher]

This crash may also result from the fact that the socket output stream does
not own the socket transport.  So, I would suggest verifying that you haven't
released the socket transport before the output stream.  But, even if this 
ownership model isn't "fixed" ... some error checking needs to be added to
the socket transport to avoid this kind of crash.

Comment 3

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

this bug isn't fixed, but I've checked in a patch so we don't send "ARTICLE <"
if we get into this bogus state on exit.

I still need to debug this problem and figure out how we got into that bogus state.

Comment 4

[scottputterman]

Seth is the patch you checked in sufficient for the moment, or is there some
other problem that you know about that will happen because of it?

Comment 5

[Darin Fisher]

please look at my patch for bug 72320.  i think that it is the right fix for
this problem as well.

Comment 6

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

yes, this is a dup of that other bug.

*** This bug has been marked as a duplicate of 72320 ***

Comment 7

[[e-mail] (gone - use [e-mail] instead)]

verified dup (per seth's comments, and reading the bug)