Crash in dav1d_ipred_z1_avx2
Categories
(Core :: Audio/Video: Playback, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox64 | --- | unaffected |
firefox65 | --- | unaffected |
firefox66 | --- | fixed |
People
(Reporter: marcus.husar, Assigned: achronop)
References
Details
(Keywords: crash, regression)
Crash Data
Attachments
(6 files)
Updated•6 years ago
|
Updated•6 years ago
|
Assignee | ||
Comment 1•6 years ago
|
||
Assignee | ||
Comment 2•6 years ago
|
||
Reporter | ||
Comment 3•6 years ago
|
||
Comment 4•6 years ago
|
||
Reporter | ||
Comment 5•6 years ago
|
||
Assignee | ||
Comment 6•6 years ago
|
||
Reporter | ||
Comment 7•6 years ago
|
||
My nasm version is 2.13.03.
Assignee | ||
Comment 8•6 years ago
|
||
Thanks Marcus. Would be possible to roll back your nasm to version 2.13.01 and attempt a new build. There is a known bug in that version of nasm that might trigger those crash. If you cannot do it no worries, I will try it.
Reporter | ||
Comment 9•6 years ago
|
||
Now I downgraded to nasm 2.13.01. After that I restarted my machine and compiled everything again after deleting the obj-x86_64-pc-linux-gnu folder. With dav1d enabled I still can’t reproduce a crash with my usual test video (https://www.youtube.com/watch?v=KOOhPfMbuIQ with AV1 and Opus).
I looked into the Fedora src git. I used version 2.13.0.1-4. It has a fix for use-after-free and heap buffer overflow vulnerabilities. I’ll try to find an older version.
See: https://src.fedoraproject.org/cgit/rpms/nasm.git/log/?h=f27
Assignee | ||
Comment 10•6 years ago
|
||
Thank you very much for looking at this. I have done the same thing and I cannot crash. I am on fedora also and same version of nasm:
Last metadata expiration check: 1:22:37 ago on Tue 08 Jan 2019 04:43:20 PM EET.
Installed Packages
nasm.x86_64 2.13.01-4.fc27 @fedora
I have raised that issue in dav1d, they suggest that 2.13.1 should be sufficient. I am checking this comment [1].
[1] https://code.videolan.org/videolan/dav1d/issues/225#note_27075
Assignee | ||
Comment 11•6 years ago
|
||
Hmm also the nasm fix is for MachO64. We must look elsewhere for that crash ...
Reporter | ||
Comment 12•6 years ago
|
||
Now I just recompiled media/libdav1d. Still can’t reproduce a crash with nasm 2.13.01-1 (fc26).
Assignee | ||
Comment 13•6 years ago
|
||
Hi Marcus, this is a debug build of the latest Nightly (Linux x64) . Could you try it and tell me if it crashes for you? Thank you in advance.
Reporter | ||
Comment 14•6 years ago
|
||
This is the output of a crashing media playback thread from gdb. Gdb bt and disassemble.
Reporter | ||
Comment 15•6 years ago
|
||
Here’s another backtrace with line numbers. This should help a lot.
I used a python script to get some symbols for gdb (source patch/to/symbols.py; https://gist.github.com/luser/193572147c401c8a965c).
Assignee | ||
Comment 16•6 years ago
|
||
Marcus tried the debug build on his system and it did not crash, opt build keep crashing. The GDB outputs above are from the opt build, latest Nightly.
Reporter | ||
Comment 17•6 years ago
|
||
Output of gdb info all-registers.
A developer in a videolan bug report asked for more information. I’ll attach the output here to have all information in one place.
See https://code.videolan.org/videolan/dav1d/issues/235 for reference.
Assignee | ||
Comment 18•6 years ago
|
||
Thank you Marcus for following up. It's nice to have the all information in one place. I reported it in dav1d issue: https://code.videolan.org/videolan/dav1d/issues/235#note_27695
Somebody suggested that would be useful if you could connect on dav1d's channels on IRC, in case they need to debug interactively. I am forwarding this suggestion in case you can. Thanks!
Reporter | ||
Comment 19•6 years ago
|
||
Yes, I could conncect to dav1d’s channel on IRC. The question is, when is the right time? My timezone is CET respectively UTC+1. If a fast internet conncetion is needed, it would be possible from 9 to 5 (or later). Downloading large amounts of data at home takes too much time.
Assignee | ||
Comment 20•6 years ago
|
||
Regarding IRC I don't think it's necessary for now. Dav1d people resulted in that the crash is caused because of the stack alignment, it is not 32 bytes aligned as it should be. This is odd because we set all the necessary flags on the compiler in order to create 32 bytes alignment.
One solution would be to return to 16 bytes alignment which is the default. Actually, I will create a custom build with that and I'll let you know in order to test it if possible, since the problem does not appear here.
A second thing I would like you to try, when you have the time, is to test the latest Nightly. I have done a new import from upstream (in Bug 1520174) and that could affect it. The fix should be in your latest Nightly by now. No need to provide any GDB output just let us know if it is crashing for you or not.
Thanks!
Reporter | ||
Comment 21•6 years ago
|
||
A few minutes ago I updated to latest nightly. It should be the one from 11:48 (UTC?). Bug 1520174 has been merged 21 hours ago. So these fixes should be in the latest Nightly. The browser is still crashing when dav1d is used.
Assignee | ||
Comment 22•6 years ago
|
||
Thank you Marcus. In [1] you can find a Firefox for Linux 64 (opt build) with stack alignment set to 16 bytes (this is coming from run [2]). I have tested locally and it works. Can you please try it and tell us if it still crashes?
[1] https://queue.taskcluster.net/v1/task/LwRgAUn4RuGxT60GPzbvDA/runs/0/artifacts/public/build/target.tar.bz2
[2] https://treeherder.mozilla.org/#/jobs?repo=try&revision=361d7db8622d82f45db7f3f60a345dcc1438f6e7&selectedJob=222447869
Reporter | ||
Comment 23•6 years ago
|
||
I confirm that the Firefox build from comment 22 works without a crash. Dav1d is activated.
Assignee | ||
Comment 24•6 years ago
|
||
Comment 25•6 years ago
|
||
Comment 26•6 years ago
|
||
bugherder |
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Description
•