Closed Bug 1813063 Opened 1 year ago Closed 1 year ago

crash at null in [@ Length]

Categories

(Core :: Audio/Video: Playback, defect, P1)

Product:
Core
Component:
Audio/Video: Playback
Type:
defect

Tracking

()

Status:
RESOLVED MOVED
Tracking Flags:
Tracking Status
firefox-esr102 --- unaffected
firefox109 --- unaffected
firefox110 --- unaffected
firefox111 + fixed

People

(Reporter: tsmith, Assigned: padenot)

References

(Blocks 1 open bug, Regression)

Details

(4 keywords, Whiteboard: [bugmon:bisected,confirmed])

Attachments

(1 file, 1 obsolete file)

testcase.mp4
2.22 KB, video/mp4
Details
Attached video testcase.mp4 —

Found while fuzzing m-c 20230127-f75c73066b88 (--enable-address-sanitizer --enable-fuzzing)

To reproduce via Grizzly Replay:

$ pip install fuzzfetch grizzly-framework
$ python -m fuzzfetch -a --fuzzing -n firefox
$ python -m grizzly.replay ./firefox/firefox testcase.mp4

==33068==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f145546ad68 bp 0x7f142f338910 sp 0x7f142f3384c0 T42606)
==33068==The signal is caused by a READ memory access.
==33068==Hint: address points to the zero page.
    #0 0x7f145546ad68 in Length /builds/worker/checkouts/gecko/dom/media/mp4/MP4Metadata.cpp:33:55
    #1 0x7f145546ad68 in mozilla::MP4AudioInfo::Update(Mp4parseTrackInfo const*, Mp4parseTrackAudioInfo const*, mozilla::IndiceWrapper const*) /builds/worker/checkouts/gecko/dom/media/mp4/DecoderData.cpp:201:45
    #2 0x7f1455483af3 in mozilla::MP4Metadata::GetTrackInfo(mozilla::TrackInfo::TrackType, unsigned long) const /builds/worker/checkouts/gecko/dom/media/mp4/MP4Metadata.cpp:367:18
    #3 0x7f145547eb96 in mozilla::MP4Demuxer::Init() /builds/worker/checkouts/gecko/dom/media/mp4/MP4Demuxer.cpp:160:20
    #4 0x7f14543d6f80 in mozilla::BenchmarkPlayback::DemuxSamples() /builds/worker/checkouts/gecko/dom/media/Benchmark.cpp:192:13
    #5 0x7f14544379fa in operator() /builds/worker/checkouts/gecko/dom/media/Benchmark.cpp:145:59
    #6 0x7f14544379fa in mozilla::detail::RunnableFunction<mozilla::Benchmark::Run()::$_14::operator()() const::'lambda'()>::Run() /builds/worker/workspace/obj-build/dist/include/nsThreadUtils.h:546:5
    #7 0x7f144e1fa216 in mozilla::TaskQueue::Runner::Run() /builds/worker/checkouts/gecko/xpcom/threads/TaskQueue.cpp:259:20
    #8 0x7f144e225886 in nsThreadPool::Run() /builds/worker/checkouts/gecko/xpcom/threads/nsThreadPool.cpp:313:14
    #9 0x7f144e21866b in nsThread::ProcessNextEvent(bool, bool*) /builds/worker/checkouts/gecko/xpcom/threads/nsThread.cpp:1191:16
    #10 0x7f144e222144 in NS_ProcessNextEvent(nsIThread*, bool) /builds/worker/checkouts/gecko/xpcom/threads/nsThreadUtils.cpp:477:10
    #11 0x7f144f966374 in mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) /builds/worker/checkouts/gecko/ipc/glue/MessagePump.cpp:300:20
    #12 0x7f144f7e8b27 in RunInternal /builds/worker/checkouts/gecko/ipc/chromium/src/base/message_loop.cc:381:10
    #13 0x7f144f7e8b27 in RunHandler /builds/worker/checkouts/gecko/ipc/chromium/src/base/message_loop.cc:374:3
    #14 0x7f144f7e8b27 in MessageLoop::Run() /builds/worker/checkouts/gecko/ipc/chromium/src/base/message_loop.cc:356:3
    #15 0x7f144e210145 in nsThread::ThreadFunc(void*) /builds/worker/checkouts/gecko/xpcom/threads/nsThread.cpp:383:10
    #16 0x7f14702bd628 in _pt_root /builds/worker/checkouts/gecko/nsprpub/pr/src/pthreads/ptthread.c:201:5
    #17 0x7f1470d08608 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x8608) (BuildId: 7b4536f41cdaa5888408e82d0836e33dcf436466)
    #18 0x7f14708b3132 in clone (/lib/x86_64-linux-gnu/libc.so.6+0x11f132) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
Flags: in-testsuite?

Verified bug as reproducible on mozilla-central 20230127094652-f75c73066b88.
The bug appears to have been introduced in the following build range:

Start: 4af274d4ee613437631074174934b5739d002880 (20230126212606)
End: 611d8c6d5ce8ac18a94f8a667b8cc14b6f0f4757 (20230126174851)
Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4af274d4ee613437631074174934b5739d002880&tochange=611d8c6d5ce8ac18a94f8a667b8cc14b6f0f4757

Keywords: regression
Whiteboard: [bugmon:bisected,confirmed]

:padenot looks like Bug 1703812 is the regressor?
What's the severity of this for the Firefox 111 release?

Flags: needinfo?(padenot)

Dunno about the severity, I'll get a fix tomorrow. This files allocates all the memory on my computer in a debug build somehow.

Assignee: nobody → padenot
Flags: needinfo?(padenot)

Actually no it's trivial, here's a patch. I'll add a test (and would like to figure out why it's OOMing).

Based on comment #1, this bug contains a bisection range found by bugmon. However, the Regressed by field is still not filled.

:padenot, if possible, could you fill the Regressed by field and investigate this regression?

For more information, please visit auto_nag documentation.

Flags: needinfo?(padenot)
Severity: -- → S1
tracking-firefox110: --- → ?
tracking-firefox111: --- → ?
Flags: needinfo?(padenot)
Priority: -- → P1

Setting Bug 1703812 as the regressor.
Bug 1703812 landed in 111, no need to track for 110.

tracking-firefox110: ? → ---
tracking-firefox111: ? → +
Regressed by: 1703812

Set release status flags based on info from the regressing bug 1703812

status-firefox109: --- → unaffected
status-firefox110: --- → unaffected
status-firefox-esr102: --- → unaffected
Pushed by padenot@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/bc47fb3cd3e3
Null-check aIndices when determining the total media time: some mp4 files don't have an index. r=alwu

Testcase crashes using the initial build (mozilla-central 20230127094652-f75c73066b88) but not with tip (mozilla-central 20230204091116-193873a76970.)

The bug appears to have been fixed in the following build range:

Start: 8dfe63fbc302f61029f4f652942e4628b4a1b209 (20230127165641)
End: 72da2fb0aab1c5cd50aee0b7759eb4678a2d84b8 (20230127202057)
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=8dfe63fbc302f61029f4f652942e4628b4a1b209&tochange=72da2fb0aab1c5cd50aee0b7759eb4678a2d84b8

Removing bugmon keyword as no further action possible. Please review the bug and re-add the keyword for further analysis.

Keywords: bugmon

:padenot please take a look at the severity of this?
Since there don't seem to be reports of crashes other than fuzzing, it an S1?

Pushed by padenot@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a969c8d9edc4
Null-check aIndices when determining the total media time: some mp4 files don't have an index. r=alwu

Backed out for causing crashtests on dom/media/test/crashtests/noindex.mp4.

Matthew, turns out this is also a crashtest for mp4parse, see the stack in the backout.

Flags: needinfo?(padenot) → needinfo?(kinetik)

(In reply to Paul Adenot (:padenot) from comment #15)

Matthew, turns out this is also a crashtest for mp4parse, see the stack in the backout.

Thanks for the ping. I've pushed a possible fix for review: https://github.com/mozilla/mp4parse-rust/pull/394

Flags: needinfo?(kinetik)

Setting 111 to fixed, bug 1703812 the regressor was backed out.

status-firefox111: affected → fixed

Comment on attachment 9314920 [details]
Bug 1813063 - Null-check aIndices when determining the total media time: some mp4 files don't have an index. r?alwu

Revision D168291 was moved to bug 1703812. Setting attachment 9314920 [details] to obsolete.

Attachment #9314920 - Attachment is obsolete: true
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → MOVED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: