MozillaZine

onOutputStreamReady problem and _purecall GC crash

Talk about add-ons and extension development.
Luckyrat
 
Posts: 5
Joined: February 24th, 2009, 11:18 am

Post Posted May 25th, 2010, 2:51 pm

Hi,

I have a javascript object in an add-on that makes an SSL connection to a local (high) port and implements nsIOutputStreamCallback.onOutputStreamReady() so that I can respond to the result of the connection attempt appropriately.

I've hit a couple of problems (the second as a result of working around the first) and so I have a few questions.

1) The onOutputStreamReady() documentation says that it should be called when the stream is writeable or closed but under no circumstances does nsISocketTransport.isAlive() return true when I call that function in an onOutputStreamReady() implementation. Is there an alternative way to differentiate between when the function has been called when the stream is writeable and when it has been closed?

As a result of the unexpected behaviour regarding isAlive() I fudged a short delay timer as shown in the code below. The onConnectDelayTimerAction() function uses nsISocketTransport.isAlive() to successfully detect that the stream is writeable (or not if the connection to the remote server could not be established for some reason).

Code: Select all
onOutputStreamReady: function()
{
  var wm = Cc["@mozilla.org/appshell/window-mediator;1"]
     .getService(Ci.nsIWindowMediator);
  var window = wm.getMostRecentWindow("navigator:browser");

  var rpc = window.keeFoxInst.KeePassRPC;

  rpc.onConnectDelayTimer = Cc["@mozilla.org/timer;1"].createInstance(Ci.nsITimer);

  rpc.onConnectDelayTimer.initWithCallback(rpc.onConnectDelayTimerAction,
     1000, Ci.nsITimer.TYPE_ONE_SHOT);
}


The above works fine 999 times out of 1000 but when it doesn't work it fails spectacularly, crashing firefox with a "_purecall | nsXPCWrappedJS::QueryInterface(nsID const&, void**)" message. I submitted a few to the Mozilla crash reporting system so I could try to spot a pattern or similar crashes that might give me a clue what I'm doing wrong:

http://crash-stats.mozilla.com/report/index/bc658a03-e0b0-4094-9562-6438f2100524
http://crash-stats.mozilla.com/report/index/ef2a3fc2-19f6-4a78-bedd-c9d652100523
http://crash-stats.mozilla.com/report/index/40c1d6cb-1a05-4bfd-9685-4d1b82100523

2) Is this expected? I.e. have I made a stupid mistake somewhere in that code such as misunderstanding some known multi-threading behaviour? (I'm not aware of any of this code running on multiple threads but with network access and timers involved I suspect that may happen behind the scenes)

3) If the code looks OK, does anyone know if this could be exposing an application bug?

One interesting point I noticed from the crash submissions was that there were some other related crashes (mostly from Thunderbird) logged under this bug - they appear to all crash during garbage collection and have a thread in a similar state (e.g. thread 4 in the first report above). That looks like the thread which has performed the callback to my onOutputStreamReady(); a logging statement inserted at the end of the above function succeeds every time - maybe that means something to someone?

In case it's relevant, the same javascript object also implements other interfaces: nsIBadCertListener2, nsIInterfaceRequestor, nsIStreamListener, nsITransportEventSink and nsIOutputStreamCallback.

I'll try to help explore the underlying cause of bug 505016 if it's related but I'd also like to find a way that my add-on can just work without crashing Firefox so if anyone has any bright ideas of ways I can work around these issues in the mean-time that would be most appreciated.

Thanks,
Chris

Return to Extension Development


Who is online

Users browsing this forum: No registered users and 3 guests