510960 - [exit] Mozmill should check for running jsbridge instances on exit

Status: RESOLVED DUPLICATE of bug 584464

(Testing Graveyard :: Mozmill, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

If an exception is thrown in mozmill while a test is running we do not shutdown jsbridge. That will cause errors like that on the next run:

jsbridge: Exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIServerSocket.init]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: file:///private/var/folders/w2/w2myuXRLE1q1Ex7puQAPYk+++TI/-Tmp-/tmpphV4j7.mozrunner/extensions/[e-mail]/resource/modules/server.js :: anonymous :: line 274"  data: no]

We should enhance our try/catch blocks to catch such an exception and shutdown jslib before exiting Mozmill.

Comment 1

[cmtalbert]

Jeff, isn't this fixed in your refactoring for merging restart/nonrestart tests?  

--> DUPE of bug 584464?

Comment 2

[Jeff Hammel]

I'm not sure, to be honest.  checking for running instances of JS bridge may not be done.  that said, it is likely (though hard to tell in the wild for all edge cases since we don't have reproduction steps) that bug 584464 fixes this.  That said, the actionable item

"We should enhance our try/catch blocks to catch such an exception and shutdown
jslib before exiting Mozmill."

*IS* done there, abict

Comment 3

[cmtalbert]

All actionable activity taking place in another bug, open a new bug with clear steps if more needs to be done.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Jeff, does bug 584464  really fix that?

Comment 5

[Jeff Hammel]

I'm not sure if we can say with any definativeness if bug 584464 solves this or not.  I think we can safely say:

- we *SHOULD* clean up correctly and in an idempotent way; bug 584464 as well as several other bugs have greatly improved this
- it is impossible to know if we have cleaned up completely correctly or not: http://en.wikipedia.org/wiki/Halting_problem ; the best we can do is make it better and better such that reliability is high and (again, we've come a long way here) having programmatic ways to make cleanup reliably happen as a response to, um, dirtying makes this much better
- see also comment 2; ABICT the actionable item of this bug is addressed
- I haven't seen this bug in a long time; it is hard to reproduce; it is hard to know how long to keep a bug open when it does not reoccur and there are no tests and reproduction steps
- there aren't any tests or reproduction steps on this bug; i don't know if keeping it open as a blanket bug is particularly useful

$0.02

Comment 6

[cmtalbert]

(In reply to comment #5)
> I'm not sure if we can say with any definativeness if bug 584464 solves this or
> not.  I think we can safely say:
> 
> - we *SHOULD* clean up correctly and in an idempotent way; bug 584464 as well
> as several other bugs have greatly improved this
> - it is impossible to know if we have cleaned up completely correctly or not:
> http://en.wikipedia.org/wiki/Halting_problem ; the best we can do is make it
> better and better such that reliability is high and (again, we've come a long
> way here) having programmatic ways to make cleanup reliably happen as a
> response to, um, dirtying makes this much better
> - see also comment 2; ABICT the actionable item of this bug is addressed
> - I haven't seen this bug in a long time; it is hard to reproduce; it is hard
> to know how long to keep a bug open when it does not reoccur and there are no
> tests and reproduction steps
> - there aren't any tests or reproduction steps on this bug; i don't know if
> keeping it open as a blanket bug is particularly useful
> 
> $0.02

Yes all of that is true.  There is no use in keeping vague useless bugs like this open.  We believe that we have improved and maybe fixed this, so let's make that assumption and if it proves not to be the case, we'll open a new bug.