Closed Bug 618052 Opened 14 years ago Closed 13 years ago

Intermittent test_utils_queryAsync.js | test failed (with xpcshell return code: 0) | false == true

Categories

(Firefox :: Sync, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla5
Tracking Status
firefox5 --- fixed

People

(Reporter: rnewman, Assigned: rnewman)

References

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

Make sure updates work
TEST-PASS | /Users/rnewman/moz/hg/services/fx-sync/services/sync/tests/unit/test_utils_queryAsync.js | [run_test : 54] 0 == 0
Get the updated
TEST-PASS | /Users/rnewman/moz/hg/services/fx-sync/services/sync/tests/unit/test_utils_queryAsync.js | [run_test : 58] 1 == 1
TEST-PASS | /Users/rnewman/moz/hg/services/fx-sync/services/sync/tests/unit/test_utils_queryAsync.js | [run_test : 59] more == more
TEST-PASS | /Users/rnewman/moz/hg/services/fx-sync/services/sync/tests/unit/test_utils_queryAsync.js | [run_test : 60] updated == updated
Grabbing fewer fields than queried is fine
TEST-PASS | /Users/rnewman/moz/hg/services/fx-sync/services/sync/tests/unit/test_utils_queryAsync.js | [run_test : 64] 3 == 3
Generate an execution error
TEST-UNEXPECTED-FAIL | /Users/rnewman/moz/hg/services/fx-sync/services/sync/tests/unit/test_utils_queryAsync.js | false == true - See following stack:
JS frame :: /Users/rnewman/moz/hg/mozilla-central/testing/xpcshell/head.js :: do_throw :: line 424
JS frame :: /Users/rnewman/moz/hg/mozilla-central/testing/xpcshell/head.js :: do_check_eq :: line 476
JS frame :: /Users/rnewman/moz/hg/mozilla-central/testing/xpcshell/head.js :: do_check_true :: line 488
JS frame :: /Users/rnewman/moz/hg/services/fx-sync/services/sync/tests/unit/test_utils_queryAsync.js :: run_test :: line 73
JS frame :: /Users/rnewman/moz/hg/mozilla-central/testing/xpcshell/head.js :: _execute_test :: line 307
JS frame :: -e :: <TOP_LEVEL> :: line 1
TEST-INFO | (xpcshell/head.js) | exiting test
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1293676232.1293677281.13896.gz
Rev3 MacOSX Snow Leopard 10.6.2 mozilla-central debug test xpcshell on 2010/12/29 18:30:32
s: talos-r3-snow-005
Blocks: 438871
Whiteboard: [orange]
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1295449436.1295450037.9714.gz
Rev3 MacOSX Snow Leopard 10.6.2 mozilla-central opt test xpcshell on 2011/01/19 07:03:56
s: talos-r3-snow-035
Summary: test_utils_queryAsync sometimes fails → Intermittent test_utils_queryAsync.js | test failed (with xpcshell return code: 0) | false == true
For reasons unknown, removing the condition here http://hg.mozilla.org/mozilla-central/file/1a89509e25e4/testing/xpcshell/runxpcshelltests.py#l168, i.e. always turning on tracemalloc backtraces, seems to increase the frequency of the intermittent failure here.  It's still intermittent, just more frequent.
(In reply to comment #22)
> For reasons unknown, removing the condition here
> http://hg.mozilla.org/mozilla-central/file/1a89509e25e4/testing/xpcshell/runxpcshelltests.py#l168,
> i.e. always turning on tracemalloc backtraces, seems to increase the frequency
> of the intermittent failure here.  It's still intermittent, just more frequent.

I've also been noticing that test_queryAsync fails much more frequently on my MacBook Pro in the past month (on services-central, which is behind m-c right now).

I spent a morning on it, but was unable to narrow it down to anything fixable in the test.
queryAsync's mozIStorageStatementCallback handlers didn't expect to be called both on error and on completion. That led to the callback being called twice -- once to throw the error, and then again with an empty result set.

Catching this just right meant that an error would be silently swallowed, resulting in this storm of random orange.

The fix is to check the reason code, and return appropriately.

I also constantified some things, switched to a query that's guaranteed to fail regardless of the content of the DB, and turned on logging for this test.
Assignee: nobody → rnewman
Status: NEW → ASSIGNED
Attachment #526893 - Flags: review?(philipp)
Comment on attachment 526893 [details] [diff] [review]
Proposed patch. v1

<3
Attachment #526893 - Flags: review?(philipp) → review+
Landed on m-c to kill oranges fast or your money back:

http://hg.mozilla.org/mozilla-central/rev/0e8c23e50c6c

Will merge into s-c when I see green, then resolve this bug.
Pushed to s-c.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Comment on attachment 526893 [details] [diff] [review]
Proposed patch. v1

Requesting Aurora approval for killing a random orange.
Attachment #526893 - Flags: approval-mozilla-aurora?
(In reply to comment #64)

> Rev3 MacOSX Snow Leopard 10.6.2 mozilla-aurora debug test xpcshell on
> 2011/04/19 14:46:17

Exactly :D
Comment on attachment 526893 [details] [diff] [review]
Proposed patch. v1

Because this also touches non-test code and does not impact users, we should live with this for 5.
Attachment #526893 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora-
(In reply to comment #66)
> Because this also touches non-test code and does not impact users

I should clarify: the problem wasn't actually the test, it's a bug in the code (racing callbacks). That's why it touches non-test code. Users could be impacted by this (the race could occur in production code just as much as in tests.)
Comment on attachment 526893 [details] [diff] [review]
Proposed patch. v1

Renominating this for Aurora, please see comment 67 for clarified justification.
Attachment #526893 - Flags: approval-mozilla-aurora- → approval-mozilla-aurora?
Comment on attachment 526893 [details] [diff] [review]
Proposed patch. v1

Fast fast, please!
Attachment #526893 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(In reply to comment #69)

> Fast fast, please!

On it; will land before lunch.
Target Milestone: --- → mozilla5
Whiteboard: [orange]
Component: Firefox Sync: Backend → Sync
Product: Cloud Services → Firefox
You need to log in before you can comment on or make changes to this bug.