Closed Bug 949166 Opened 11 years ago Closed 11 years ago

Intermittent cppunittests "Assertion failed: r == 0, file media/libcubeb/tests/test_sanity.cpp, line 173"

Categories

(Core :: Audio/Video, defect)

Product:
Core
Component:
Audio/Video
Platform:
x86_64
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla31
Tracking Flags:
Tracking Status
firefox29 --- unaffected
firefox30 --- unaffected
firefox31 --- fixed
firefox-esr24 --- unaffected

People

(Reporter: RyanVM, Assigned: padenot)

References

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

Actually compile the Windows 7 detection code in cubeb's test to disable part of a test. r=
(deleted), patch
kinetik
: review+
Details | Diff | Splinter Review
https://tbpl.mozilla.org/php/getParsedLog.php?id=31812617&tree=Mozilla-Inbound Rev4 MacOSX Snow Leopard 10.6 mozilla-inbound debug test cppunit on 2013-12-11 08:09:34 PST for push f7b9dc991a45 slave: talos-r4-snow-079 08:14:42 INFO - cppunittests INFO | Running test TestPLDHash 08:14:44 INFO - pldhash: for the table at address 0x7fff5fbff318, the given entrySize of 1024 definitely favors chaining over double hashing. 08:31:24 INFO - mozprocess timed out 08:31:25 ERROR - timed out after 1000 seconds of no output 08:31:25 ERROR - Return code: -9
Depends on: 994830
(Morphing summary for latest and most common variant of this) Paul, could you take a look? :-)
Blocks: 946618
Component: XPCOM → Video/Audio
No longer depends on: 994830
Flags: needinfo?(paul)
Summary: Intermittent cppunittests timed out after 1000 seconds of no output → Intermittent cppunittests "Automation Error: mozprocess timed out after 1000 seconds" (after: "Assertion failed: r == 0, file media/libcubeb/tests/test_sanity.cpp, line 173")
Depends on: 994830
Summary: Intermittent cppunittests "Automation Error: mozprocess timed out after 1000 seconds" (after: "Assertion failed: r == 0, file media/libcubeb/tests/test_sanity.cpp, line 173") → Intermittent cppunittests "timed out after 1000 seconds of no output" (after: "Assertion failed: r == 0, file media/libcubeb/tests/test_sanity.cpp, line 173")
Oops, I missed this bug, sorry, I'll write a patch right away. Thanks for the needinfo, Ed. Apparently, creating that much stream in a _really_ short time is not a good idea. This really is a stress test, I'll lower the number of streams and maybe add a recovery period. I'll note that Windows/WASAPI seems to be affected more than Windows/WinMM, and then OSX, and only a few occurrences of Linux.
Flags: needinfo?(paul)
Ok, so it appears that the |GetVersion()| system call cannot be trusted: I specifically removed some tests from the test suite when running on Windows 7 because they where failure prone, and I see them running on tbpl, but a only during a fraction of the runs. Fun. mfbt has some code that looks more complicated, there is probably a reason for that, I'll borrow it and see if it fixes it.
Great! Thank you :-)
So, I pushed a patch to try [1] to use the other method to detect the OS version, and I still nonsensical results: The test that fails is guarded by the version check that should prevent it to run on windows 7, and still runs on Windows 7. Are we certain the machines reported as being Windows 7 machine are actually Windows 7 machines ? Is something wrong with some slaves ? emk, I see you've written some version detection code, do you have any clue of what's happening here ? Specifically, |test_init_start_stop_destroy_multiple_streams| is behind the if(!is_windows_7()) check, and I see it in the tbpl log. Then, I don't see my fprintf(stderr, ...) calls in the log when it succeeds on Windows 7, only when it fails, and only for my test. Are we doing something special with stderr, only on Windows 7 ? [1]: https://tbpl.mozilla.org/?tree=Try&rev=2505b71284d3
Flags: needinfo?(VYV03354)
MSVC doesn't define the __WIN32__ preprocessor macro, so the code will not be even compiled. Use #if defined(_WIN32) || defined(__WIN32__) instead.
Flags: needinfo?(VYV03354)
Assignee: nobody → paul
Status: NEW → ASSIGNED
Attachment #8406046 - Flags: review?(kinetik) → review+
Looks like Ubuntu VMs are also failing. Is it really correct to wallpaper the underlying issue?
emk, this is not the same test that is failing (test_sanity.exe vs. test_latency for the linux here). The code path are not the same at all, I think sherrifs are filing the linux one in this bug by mistake. However, I'm looking into the Linux issue as well, don't worry.
https://hg.mozilla.org/mozilla-central/rev/0a228725aa5c
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
This bug has morphed so many times at this point that it's not really actionable for much of anything. Let's just call it fixed and get on with life. Thankfully the harness is being fixed to not generically timeout for pretty much any failures that occur.
status-firefox29: --- → unaffected
status-firefox30: --- → unaffected
status-firefox31: --- → fixed
status-firefox-esr24: --- → unaffected
Bug 996770 is filed for the test_latency failures.
Summary: Intermittent cppunittests "timed out after 1000 seconds of no output" (after: "Assertion failed: r == 0, file media/libcubeb/tests/test_sanity.cpp, line 173") → Intermittent cppunittests "Assertion failed: r == 0, file media/libcubeb/tests/test_sanity.cpp, line 173"
(To reduce risk of future false TBPL positives)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: