Bugzilla

As we've ensured that the seek time is non-negative and invalid in `MediaDecoder` [1], so the time in seek target should always valid. However, sometime we would adjust [2] the time in seek target, which only ensures that the new time should be valid but doesn't ensure the time is non-negative.

The crash seems happening in [3], which might be caused if (1) `aTime` is invalid (2) `aTime` is valid but it's a super small negative value (3) `mManager->HighestStartTime(mType)` is invaild (4) `mManager->HighestStartTime(mType)` is valid but it's a super small negative value. In addition, Jya mentioned in [4] that "`mManager->HighestStartTime(mType)` can't overflow and can't be negative". So the possibilities might be (1) and (2).

However, I didn't find any possible place where `aTime` is invalid for now, as I mentioned above, `MediaDecoder` has ensured that the time in seek target is always valid and non-negative. So now I'm looking for any possiblility that whether `MediaFormatReader` uses the unproper value for seeking.

For (2), we could add a check in `SeekTarger::SetTime()` to ensure that new seek time should always be non-negative.

[1] https://searchfox.org/mozilla-central/rev/6dab6dad9cc852011a14275a8b2c2c03ed7600a7/dom/media/MediaDecoder.cpp#592-594
[2] https://searchfox.org/mozilla-central/rev/6dab6dad9cc852011a14275a8b2c2c03ed7600a7/dom/media/SeekTarget.h#46-49
[3] https://searchfox.org/mozilla-central/rev/6dab6dad9cc852011a14275a8b2c2c03ed7600a7/dom/media/mediasource/MediaSourceDemuxer.cpp#391-397
[4] https://phabricator.services.mozilla.com/D27136#798322

As we've ensured that the seek time is non-negative and invalid in `MediaDecoder` [1], so the time in seek target should be always valid. However, sometime we would adjust [2] the time in seek target, which only ensures that the new time should be valid but doesn't ensure the time is non-negative.

The crash seems happening in [3], which might be caused if (1) `aTime` is invalid (2) `aTime` is valid but it's a super small negative value (3) `mManager->HighestStartTime(mType)` is invaild (4) `mManager->HighestStartTime(mType)` is valid but it's a super small negative value. In addition, Jya mentioned in [4] that "`mManager->HighestStartTime(mType)` can't overflow and can't be negative". So the possibilities might be (1) and (2).

However, I didn't find any possible place where `aTime` is invalid for now, as I mentioned above, `MediaDecoder` has ensured that the time in seek target is always valid and non-negative. So now I'm looking for any possiblility that whether `MediaFormatReader` uses the unproper value for seeking.

For (2), we could add a check in `SeekTarger::SetTime()` to ensure that new seek time should always be non-negative.

[1] https://searchfox.org/mozilla-central/rev/6dab6dad9cc852011a14275a8b2c2c03ed7600a7/dom/media/MediaDecoder.cpp#592-594
[2] https://searchfox.org/mozilla-central/rev/6dab6dad9cc852011a14275a8b2c2c03ed7600a7/dom/media/SeekTarget.h#46-49
[3] https://searchfox.org/mozilla-central/rev/6dab6dad9cc852011a14275a8b2c2c03ed7600a7/dom/media/mediasource/MediaSourceDemuxer.cpp#391-397
[4] https://phabricator.services.mozilla.com/D27136#798322

As we've ensured that the seek time is non-negative and invalid in `MediaDecoder` [1], so the time in seek target should be always valid. However, sometime we would adjust [2] the time in seek target, which only ensures that the new time should be valid but doesn't ensure the time is non-negative.

The crash seems happening in [3], which might be caused if (1) `aTime` is invalid (2) `aTime` is valid but it's a super small negative value (3) `mManager->HighestStartTime(mType)` is invaild (4) `mManager->HighestStartTime(mType)` is valid but it's a super small negative value. In addition, Jya mentioned in [4] that "`mManager->HighestStartTime(mType)` can't overflow and can't be negative". So the possibilities might be (1) and (2).

However, I didn't find any possible place where `aTime` is invalid for now, as I mentioned above, `MediaDecoder` has ensured that the time in seek target is always valid and non-negative. So now I'm looking for the possibility that MediaFormat Reader uses the improper value for seeking.

For (2), we could add a check in `SeekTarger::SetTime()` to ensure that new seek time should always be non-negative.

[1] https://searchfox.org/mozilla-central/rev/6dab6dad9cc852011a14275a8b2c2c03ed7600a7/dom/media/MediaDecoder.cpp#592-594
[2] https://searchfox.org/mozilla-central/rev/6dab6dad9cc852011a14275a8b2c2c03ed7600a7/dom/media/SeekTarget.h#46-49
[3] https://searchfox.org/mozilla-central/rev/6dab6dad9cc852011a14275a8b2c2c03ed7600a7/dom/media/mediasource/MediaSourceDemuxer.cpp#391-397
[4] https://phabricator.services.mozilla.com/D27136#798322

As we've ensured that the seek time is non-negative and invalid in `MediaDecoder` [1], so the time in seek target should be always valid. However, sometime we would adjust [2] the time in seek target, which only ensures that the new time should be valid but doesn't ensure the time is non-negative.

The crash seems happening in [3], which might be caused if (1) `aTime` is invalid (2) `aTime` is valid but it's a super small negative value (3) `mManager->HighestStartTime(mType)` is invaild (4) `mManager->HighestStartTime(mType)` is valid but it's a super small negative value. In addition, Jya mentioned in [4] that "`mManager->HighestStartTime(mType)` can't overflow and can't be negative". So the possibilities might be (1) and (2).

However, I didn't find any possible place where `aTime` is invalid for now, as I mentioned above, `MediaDecoder` has ensured that the time in seek target is always valid and non-negative. So now I'm looking for the possibility that `MediaFormatReader` uses the improper value for seeking.

For (2), we could add a check in `SeekTarger::SetTime()` to ensure that new seek time should always be non-negative.

[1] https://searchfox.org/mozilla-central/rev/6dab6dad9cc852011a14275a8b2c2c03ed7600a7/dom/media/MediaDecoder.cpp#592-594
[2] https://searchfox.org/mozilla-central/rev/6dab6dad9cc852011a14275a8b2c2c03ed7600a7/dom/media/SeekTarget.h#46-49
[3] https://searchfox.org/mozilla-central/rev/6dab6dad9cc852011a14275a8b2c2c03ed7600a7/dom/media/mediasource/MediaSourceDemuxer.cpp#391-397
[4] https://phabricator.services.mozilla.com/D27136#798322

As we've ensured that the seek time is non-negative and invalid in `MediaDecoder` [1], so the time in seek target should be always valid. However, sometime we would adjust [2] the time in seek target, which only ensures that the new time should be valid but doesn't ensure the time is non-negative.

The crash seems happening in [3], which might be caused if (1) `aTime` is invalid (2) `aTime` is valid but it's a super small negative value (3) `mManager->HighestStartTime(mType)` is invaild (4) `mManager->HighestStartTime(mType)` is valid but it's a super small negative value. In addition, Jya mentioned in [4] that "`mManager->HighestStartTime(mType)` can't overflow and can't be negative". So the possibilities might be (1) and (2).

However, I didn't find any possible place where `aTime` is invalid for now, as I mentioned above, `MediaDecoder` has ensured that the time in seek target is always valid and non-negative. So now I'm looking for the possibility that `MediaFormatReader` uses the improper value for seeking.

For (2), we could add a check in `SeekTarget::SetTime()` to ensure that new seek time should always be non-negative.

[1] https://searchfox.org/mozilla-central/rev/6dab6dad9cc852011a14275a8b2c2c03ed7600a7/dom/media/MediaDecoder.cpp#592-594
[2] https://searchfox.org/mozilla-central/rev/6dab6dad9cc852011a14275a8b2c2c03ed7600a7/dom/media/SeekTarget.h#46-49
[3] https://searchfox.org/mozilla-central/rev/6dab6dad9cc852011a14275a8b2c2c03ed7600a7/dom/media/mediasource/MediaSourceDemuxer.cpp#391-397
[4] https://phabricator.services.mozilla.com/D27136#798322