Closed Bug 1632456 Opened 1 year ago Closed 1 year ago

Crash in [@ vaExportSurfaceHandle]

Categories

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

77 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla78
Tracking Status
firefox-esr68 --- unaffected
firefox75 --- unaffected
firefox76 --- unaffected
firefox77 --- wontfix
firefox78 --- fixed

People

(Reporter: calixte, Assigned: stransky)

References

(Blocks 2 open bugs, Regression)

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 file)

This bug is for crash report bp-aa02bbf4-2cc0-430d-a6b5-4eea90200422.

Top 10 frames of crashing thread:

0 libva.so.2 vaExportSurfaceHandle 
1 libxul.so mozilla::FFmpegVideoDecoder<58>::CreateImageVAAPI dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp:637
2 libxul.so mozilla::FFmpegVideoDecoder<58>::DoDecode dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp:434
3 libxul.so mozilla::FFmpegDataDecoder<58>::DoDecode dom/media/platforms/ffmpeg/FFmpegDataDecoder.cpp:184
4 libxul.so mozilla::FFmpegDataDecoder<58>::ProcessDecode dom/media/platforms/ffmpeg/FFmpegDataDecoder.cpp:140
5 libxul.so mozilla::detail::ProxyRunnable<mozilla::MozPromise<nsTArray<RefPtr<mozilla::MediaData> >, mozilla::MediaResult, true>, RefPtr<mozilla::MozPromise<nsTArray<RefPtr<mozilla::MediaData> >, mozilla::MediaResult, true> >  xpcom/threads/MozPromise.h:1353
6 libxul.so mozilla::TaskQueue::Runner::Run xpcom/threads/TaskQueue.cpp:207
7 libxul.so nsThreadPool::Run xpcom/threads/nsThreadPool.cpp:300
8 libxul.so non-virtual thunk to nsThreadPool::Run xpcom/threads/nsThreadPool.cpp
9 libxul.so nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1200

There is 1 crash in nightly 77 with buildid 20200422093542. In analyzing the backtrace, the regression may have been introduced by patch [1] to fix bug 1630754.

[1] https://hg.mozilla.org/mozilla-central/rev?node=c159181ff5d0

Flags: needinfo?(stransky)

I'll look at it, Thanks!

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

Hm, I don't see a clear reason why this happens. Maybe mDisplay is wrong, let's see if fix from Bug 1632059 helps here.

Priority: -- → P3
Severity: -- → S2

Adding a couple of similar-looking signatures.

Crash Signature: [@ vaExportSurfaceHandle] → [@ vaExportSurfaceHandle] [@ libpthread.so.0@0xa820 ] [@ libva.so.2@0x6d79 ]

I think I have a log for that:

[h264 @ 0x7fe4731a2800] Decode to surface 0x4000015.
[Child 194041: MediaPDecoder #3]: D/PlatformDecoderModule Got one VAAPI frame output with pts=137280000 dts=137280000 duration=40000 opaque=-9223372036854775808
[Child 194041, MediaDecoderStateMachine #1] WARNING: Decoder=7fe472b6bc00 Decode error: NS_ERROR_OUT_OF_MEMORY (0x8007000e) - mozilla::MediaResult mozilla::FFmpegVideoDecoder<58>::CreateImageVAAPI(int64_t, int64_t, int64_t, mozilla::MediaDataDecoder::DecodedData&): Unable to get frame by vaExportSurfaceHandle(): file /home/komat/src-wayland/dom/media/MediaDecoderStateMachine.cpp, line 3370

so looks like OOM on GPU if that's possible.

It's caused by missing mVAAPIDeviceContext release when va-api driver is missing. As mVAAPIDeviceContext is used as a flag that vaapi support is present we take vaapi path even when we failed to configure it.

Pushed by abutkovits@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/47d145c1130d
[Wayland] Release mVAAPIDeviceContext when FFmpegVideoDecoder::CreateVAAPIDeviceContext() fails, r=jya
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla78
You need to log in before you can comment on or make changes to this bug.