Test failures on OSX when building with clang 5

RESOLVED FIXED in Firefox 58

Status

()

defect
P3
normal
Rank:
25
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: glandium, Assigned: padenot)

Tracking

unspecified
mozilla58
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox58 fixed)

Details

Attachments

(1 attachment)

Reporter

Description

2 years ago
They all seem to root to the following assertion:

INFO - [Child 1855, Unnamed thread 11facbda0] ###!!! ASSERTION: Bad seconds: '0 <= aSeconds && aSeconds <= TRACK_TICKS_MAX/TRACK_RATE_MAX', file /builds/worker/workspace/build/src/dom/media/MediaStreamGraph.h, line 469

Logs:
https://treeherder.mozilla.org/logviewer.html#?job_id=137763477&repo=autoland
https://treeherder.mozilla.org/logviewer.html#?job_id=137690275&repo=autoland

You can check on try by pushing the patch from bug 1409265 along.
Component: Audio/Video → Audio/Video: Playback
This is in MediaStreamGraph, so not playback. Furthermore the assert is in a function only called by WebAudio. Paul?
Component: Audio/Video: Playback → Web Audio
Flags: needinfo?(padenot)
Priority: P5 → --
Rank: 25
Priority: -- → P3
Assignee

Comment 2

2 years ago
Thanks for the heads up.

I've done a try push with the clang-5 patches and some stuff to diagnose here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=994800ac79ef6507f7e24e2640f6c586459d9be8
Assignee: nobody → padenot
Flags: needinfo?(padenot)
Assignee

Comment 3

2 years ago
Of course I pushed without compiling locally, and it broke.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=f6f57441ab5ccad67359840309205b89f9324fad
Assignee

Comment 5

2 years ago
Well for some reason it does not print the stack trace and my stuff, now.
(In reply to Paul Adenot (:padenot) from comment #5)
> Well for some reason it does not print the stack trace and my stuff, now.

Don't know what happened to the stack trace, but NaNs would explain the lack of output from the printf.
Comment hidden (mozreview-request)
The alternative would be test mType before use in
WebAudioUtils::ConvertAudioTimelineEventToTicks() and before logging in
SendEventToEngine().  The latter would be a little inconvenient.

The process of initializing in the constructor was begun just for the sake of
keeping Coverity silent for bug 1232646.
I'm continuing that because I guess it will be simplest.

http://searchfox.org/mozilla-central/rev/7e090b227f7a0ec44d4ded604823d48823158c51/dom/media/webaudio/WebAudioUtils.cpp#26
http://searchfox.org/mozilla-central/rev/7e090b227f7a0ec44d4ded604823d48823158c51/dom/media/webaudio/AudioParam.cpp#158
Assignee

Comment 10

2 years ago
mozreview-review
Comment on attachment 8925791 [details]
bug 1409622 initialize mTime even in Stream AudioTimelineEvents

https://reviewboard.mozilla.org/r/196968/#review202206
Attachment #8925791 - Flags: review?(padenot) → review+
Assignee

Comment 11

2 years ago
mozreview-review
Comment on attachment 8925791 [details]
bug 1409622 initialize mTime even in Stream AudioTimelineEvents

https://reviewboard.mozilla.org/r/196968/#review202210

Comment 12

2 years ago
Pushed by ktomlinson@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1924564466fe
initialize mTime even in Stream AudioTimelineEvents r=padenot

Comment 13

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/1924564466fe
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
You need to log in before you can comment on or make changes to this bug.