1051111 - Leak of an nsAStreamCopier and friends because the continuation event is rejected

Status: NEW

(Core :: Networking, defect, P3)

Description

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

When shutting down B2G the log reliably has

WARNING: An event was posted to a thread that will never run it (rejected): file ../../../gecko/xpcom/threads/nsThread.cpp, line 463
WARNING: unable to post continuation event: file ../../../gecko/xpcom/io/nsStreamUtils.cpp, line 450

We then leak an nsAStreamCopier and the associated stuff (a pipe, the socket transport service, a socket transport, etc).  AFAICT nsSocketTransport never cancels the async copy (since it doesn't grab the copier context it shouldn't be possible for it to do so).  Not really sure whether to file this in XPCOM or Necko, so lets start here on the assumption that nsSocketTransport is wrong.

Also potentially relevant: bug 266789.

Comment 1

[Benjamin Smedberg]

It sounds to me like the problem is that we still have some stream code running this late in shutdown. So either:

1) nsAStreamCopier should observe shutdown and cancel stream copying
2) The client of nsAStreamCopier should be aware of shutdown and stop doing stuff

Do we know what stream is being copied here and whether we can fix it at the client?

Comment 2

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

I haven't verified but I believe it comes from http://mxr.mozilla.org/mozilla-central/source/toolkit/modules/Sntp.jsm#258.

Comment 3

[Jason Duell]

Patrick, got any idea here? (or an idea of who's best to look into it?)

Comment 4

[Patrick McManus [:mcmanus]]

(03:20:45 PM) mcmanus: so khuey - traditionally, and I speak only really from tradition here because I've never changed any of this, consumers of the sockettransportservice have observed shutdown themselves and done the cancel
(03:21:23 PM) mcmanus: .. and done the cancel of any open transports when the shutdown is received
(03:21:46 PM) mcmanus: so that would argue for making the change in sntp.jsm
(03:22:27 PM) mcmanus: which does seem oddly distributed of what could be a centralzied function
(03:36:22 PM) mcmanus: but it lets them cleanup in a application specific way.. the http code tries to spit out an error and then calls  sockettransport::close(ns_error_abort)

Comment 5

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 6

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258