Now that bug 597064 observes timeouts from the harness itself, we don't need the JS timer any longer. We can also remove the timeout from test_tcpsocket.js.

Is there any useful info we can get from the in-xpcshell timer that we can't from Python? I'm wondering if there's any diagnostic info we can spit out that'd still be useful.

Comment on attachment 746617 [details] [diff] [review] Remove xpcshell timeout timers. Review of attachment 746617 [details] [diff] [review]: ----------------------------------------------------------------- You didn't answer my question, but I'll r+ this anyway.

I haven't been able to find any useful information we could present from JS.

(In reply to Josh Matthews [:jdm] from comment #4) > I haven't been able to find any useful information we could present from JS. Well, except for the entire log of the failing test? :-) I've found this while investigating bug 869144. The resulting harness log file does not provide any information from the log of the failing test: https://tbpl.mozilla.org/php/getParsedLog.php?id=24774410&tree=Mozilla-Inbound#error0 So, we can't know at which point the test stopped (note that, for main thread hangs in synchronous tests, that situation may still happen even if we have the inner timeout). Unless there is a better solution, can you please file a bug to reinstate this? Maybe with some more comments than I put in the source code originally :-) Note that, since HARNESS_TIMEOUT is 5 minutes, we should either increase it or use an inner timeout that is shorter than 5 minutes (we should also put comments in both places to ensure we know that the two timeouts are related).

(In reply to Paolo Amadini [:paolo] from comment #7) > Note that, since HARNESS_TIMEOUT is 5 minutes Or, on second thought, after looking at how the patch on bug 746526 does not touch the HARNESS_TIMEOUT variable, maybe it's a different timeout interaction that is causing the issue, in which case disregard the previous comment. Any ideas?

From that log it looks like the timeout-handling code is just broken for B2G xpcshell tests. File a new bug on that?

Filed bug 889317. Josh (or others), do you confirm that the inner timeout removal in this bug does not normally prevent us from getting the test log until the point where the timeout occurred?

I'm not sure which context you're asking about. For desktop platforms, the presence or absence of the timer removed in this bug did not affect whether we could see the log after bug 597064 landed.

(In reply to Josh Matthews [:jdm] from comment #11) > I'm not sure which context you're asking about. For desktop platforms, the > presence or absence of the timer removed in this bug did not affect whether > we could see the log after bug 597064 landed. Thanks for confirming, I was asking about being able to see the log between ">>>>>>>" and "<<<<<<<" on tryserver runs, to see the various TEST-PASS and TEST-INFO executed before the timeout, but the reason why we didn't see those in this case turns out to be a B2G-specific issue.