Closed
Bug 744698
Opened 13 years ago
Closed 13 years ago
Intermittent test_nodb_pluschanges.js | command timed out: 1200 seconds without output
Categories
(Firefox :: Search, defect)
Firefox
Search
Tracking
()
RESOLVED
FIXED
Firefox 15
People
(Reporter: philor, Assigned: Yoric)
References
Details
(Keywords: intermittent-failure)
Attachments
(1 file, 4 obsolete files)
2.33 KB,
patch
|
Gavin
:
review+
|
Details | Diff | Splinter Review |
https://tbpl.mozilla.org/php/getParsedLog.php?id=10830007&tree=Mozilla-Inbound
Rev3 Fedora 12x64 mozilla-inbound debug test xpcshell on 2012-04-11 18:21:30 PDT for push bfa27d58769d
TEST-INFO | /home/cltbld/talos-slave/test/build/xpcshell/tests/toolkit/components/search/tests/xpcshell/test_nodb_pluschanges.js | running test ...
command timed out: 1200 seconds without output, attempting to kill
Comment 1•13 years ago
|
||
Assignee | ||
Comment 2•13 years ago
|
||
Investigating. Is this only on Linux 64bit?
Assignee: nobody → dteller
Assignee | ||
Comment 3•13 years ago
|
||
How comes I can't see any log?
Assignee | ||
Comment 4•13 years ago
|
||
I can't see any logs on tbpl (this test should produce pages of logs). Also, I cannot reproduce the issue and I cannot find any occurrence of on inbound it since Marco's message. Right now, I have no idea what can have gone wrong or how I can fix it.
If anybody manages to reproduce the issue, I would be very interested in the logs.
Comment 5•13 years ago
|
||
(In reply to David Rajchenbach Teller [:Yoric] from comment #2)
> Investigating. Is this only on Linux 64bit?
Comment 1 is on Mac OS X 32-bit.
The missing logging is because of bug 500388. Since this failure seems fairly rare, the best bet might be fix or work around that bug so we can get logs if it happens in the future.
OS: Mac OS X → All
Hardware: x86 → All
Assignee | ||
Comment 6•13 years ago
|
||
(In reply to Matt Brubeck (:mbrubeck) from comment #5)
> The missing logging is because of bug 500388. Since this failure seems
> fairly rare, the best bet might be fix or work around that bug so we can get
> logs if it happens in the future.
Ok. If I set a timeout internally and call |do_throw| from that timeout, this should work around bug 500388, shouldn't it?
Assignee | ||
Comment 7•13 years ago
|
||
Is this what you have in mind?
Attachment #617299 -
Flags: review?(mbrubeck)
Comment 8•13 years ago
|
||
Comment on attachment 617299 [details] [diff] [review]
Forcing timeout, to improve logging
Looks like a good idea, but I've never written an xpcshell test and am not the best person to review this. (For example, it's not clear to me whether unfired do_timeout timers are automatically cleared when the test finishes.)
Attachment #617299 -
Flags: review?(mbrubeck)
Assignee | ||
Comment 9•13 years ago
|
||
Comment on attachment 617299 [details] [diff] [review]
Forcing timeout, to improve logging
Ok, placing the burden back on Gavin.
Attachment #617299 -
Flags: review?(gavin.sharp)
Comment 10•13 years ago
|
||
Comment on attachment 617299 [details] [diff] [review]
Forcing timeout, to improve logging
>diff --git a/toolkit/components/search/tests/xpcshell/test_nodb_pluschanges.js b/toolkit/components/search/tests/xpcshell/test_nodb_pluschanges.js
>+ do_timeout(2000, function() {
2 seconds isn't that long, which might cause this test to fail where it would otherwise pass. Given that the harness timeout seems to occur after 20 minutes, you could stand to make this timeout be ~10 minutes to be sure to only catch the cases where we're truly failing.
Attachment #617299 -
Flags: review?(gavin.sharp) → review+
Assignee | ||
Updated•13 years ago
|
Keywords: checkin-needed
Whiteboard: [orange] → [orange][do-not-close-after-landing]
Assignee | ||
Comment 12•13 years ago
|
||
Comment on attachment 617403 [details] [diff] [review]
Forcing timeout, to improve logging
[Approval Request Comment]
Please see https://wiki.mozilla.org/Tree_Rules for information on mozilla-central landings that do not require approval.
Possible risk to Fennec Native 14 (if any): None, it should only impact logging of one test.
Attachment #617403 -
Flags: approval-mozilla-central?
Comment 13•13 years ago
|
||
Comment on attachment 617403 [details] [diff] [review]
Forcing timeout, to improve logging
You don't need explicit approval; you can just land this with a=test-only:
https://wiki.mozilla.org/Tree_Rules
Attachment #617403 -
Flags: approval-mozilla-central?
Assignee | ||
Comment 14•13 years ago
|
||
Here we go. Thanks, Matt.
Attachment #617403 -
Attachment is obsolete: true
Comment 15•13 years ago
|
||
Flags: in-testsuite-
Keywords: checkin-needed
Comment 16•13 years ago
|
||
> Created attachment 617550 [details] [diff] [review]
> Forcing timeout, to improve logging
https://hg.mozilla.org/mozilla-central/rev/efba113561c6
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Updated•13 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Updated•13 years ago
|
Status: REOPENED → ASSIGNED
Whiteboard: [orange][do-not-close-after-landing] → [orange][leave open]
Comment hidden (Legacy TBPL/Treeherder Robot) |
Assignee | ||
Comment 18•13 years ago
|
||
Ok, logs make it a little better. Adding more logs and what might possibly be a fix.
Attachment #617550 -
Attachment is obsolete: true
Attachment #618672 -
Flags: review?(gavin.sharp)
Comment 19•13 years ago
|
||
This patch doesn't seem to apply on top of the other one, did you attach the wrong one?
I wonder whether asyncCopy should handle explicitly closing the output stream before invoking its callback. It seems like this problem could affect many other consumers of it (who don't currently rely on immediately reading back in the written data, I guess).
Updated•13 years ago
|
Attachment #618672 -
Flags: review?(gavin.sharp)
Assignee | ||
Comment 20•13 years ago
|
||
Sorry about that, I had posted a merged patch. This one should do the trick.
Attachment #618672 -
Attachment is obsolete: true
Attachment #618944 -
Flags: review?(gavin.sharp)
Assignee | ||
Comment 21•13 years ago
|
||
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #19)
> This patch doesn't seem to apply on top of the other one, did you attach the
> wrong one?
>
> I wonder whether asyncCopy should handle explicitly closing the output
> stream before invoking its callback. It seems like this problem could affect
> many other consumers of it (who don't currently rely on immediately reading
> back in the written data, I guess).
If this patch proves to fix the issue, this definitely deserves investigation.
Assignee | ||
Updated•13 years ago
|
Keywords: checkin-needed
Updated•13 years ago
|
Attachment #618944 -
Flags: review?(gavin.sharp) → review+
Comment 24•13 years ago
|
||
applying c:\users\ed\appdata\local\temp\thg-import-5fuczc.patch
patching file toolkit/components/search/nsSearchService.js
Hunk #1 FAILED at 3781
1 out of 1 hunks FAILED -- saving rejects to file toolkit/components/search/nsSearchService.js.rej
patching file toolkit/components/search/tests/xpcshell/test_nodb_pluschanges.js
abort: patch failed to apply
Comment 25•13 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/eb164529f0d5
David, should the [leave open] still be on the whiteboard?
Keywords: checkin-needed
Target Milestone: --- → Firefox 15
Assignee | ||
Comment 26•13 years ago
|
||
You are right, we should probably close this bug and reopen it if necessary.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → FIXED
Updated•13 years ago
|
Whiteboard: [orange][leave open] → [orange]
Comment 27•13 years ago
|
||
Updated•13 years ago
|
Keywords: intermittent-failure
Updated•13 years ago
|
Whiteboard: [orange]
You need to log in
before you can comment on or make changes to this bug.
Description
•