New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Segfault in mpv's VO thread due to --opengl-pbo #4988
Comments
Does cutting the file without remuxing work? I.e. getting the first few MBs. |
Indeed it does. The "sample" is still ~450MB in size though. I'm uploading it now to 0x0 (in 2 pieces), will probably take hours with my connection. |
Apparently, at night my connection is faster than it should be |
Quick check: Does passing --no-sub fix it? |
Yes it does |
I've seen at least one similar crash in rare cases when working on my vulkan stuff as well, and other users have also reported random crashes on certain subtitle files with vulkan etc. I'm not entirely sure what causes it. The samples shared by others have always failed to reproduce the issue for me, but I've definitely encountered such crashes myself. For example, your sample plays fine. The only time I was able to look at a coredump (i.e. my own crash), the problem was that the tex_upload() call passed a source pointer that had fewer allocated bytes than the buffer expected, so it was doing an out of bounds read. (I have no idea why it doesn't crash with plain glTexData, maybe because of DMA magic) I suspect something might be amiss either in the OSD code or probably libass. Can you try updating libass to the laster |
Did that but it still crashes. |
Tried run the sample (https://0x0.st/C26.mkv) on win10: Related trace: |
linux 64bit I'm also crashing with PBO, which is a shame beause it drops my jitter to almost nothing (0.007) |
@weedy (probably) unrelated issue |
Does anyone on mac know if this is still a problem? |
mpv version and platform
mpv 0.27.0-235-g47b1390 on OSX 10.11 and yes, this is likely a OSX problem
Reproduction steps
Start a video with
mpv --no-config --opengl-pbo=yes --fs
and let it play without interaction roughly to the 2 min mark (a bit before that actually).In case certain interactions were made (e.g. leave and re-enter fullscreen or small seeks) the crash occurs a bit later. Note that
--fs
is not needed from the start, it's enough to enter fullscreen before playback happens.Expected behavior
No segfault
Actual behavior
Segfault
Log file
It segfaults roughly at 95 seconds and there's no log entry around that time.
Logfile: https://gist.github.com/Argon-/38d6c331576383ee97a291d9a5763fdc
OSX stack trace: https://gist.github.com/Argon-/786b82970e63307f55f3552430fa19c1
Sample files
So far, I've only seen one video file that leads to this crash (within the first 2 minutes). I tried to cut the first 2 min of the video but the sample doesn't exhibit this problem. I guess videos that trigger this are rare as nobody noticed this so far (or my system is botched).
The original file is around 25GB in size and basically impossible for me to upload.
I created the unaffected/useless sample using
ffmpeg -i video.mkv -ss 0 -t 120 -c copy sample.mkv
. Let me know in case someone has a better idea how to produce a sample.I have bisected the problem and the first bad commit is 46d86da
The text was updated successfully, but these errors were encountered: