Segfault in mpv's VO thread due to --opengl-pbo

Argon- commented 6 years ago

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 https://github.com/mpv-player/mpv/commit/46d86da6300ebcd2134996c76b9238fcf8e0fb6e

ghost commented 6 years ago

Does cutting the file without remuxing work? I.e. getting the first few MBs.

Argon- commented 6 years ago

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.

Argon- commented 6 years ago

Apparently, at night my connection is faster than it should be https://0x0.st/C26.mkv (230MB) https://0x0.st/C2d.bin (220MB) The original file was split into these pieces using split, so you can cat them

haasn commented 6 years ago

Quick check: Does passing --no-sub fix it?

Argon- commented 6 years ago

Yes it does

haasn commented 6 years ago

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 git master and seeing if that makes the problem go away?

Argon- commented 6 years ago

Can you try updating libass to the laster git master and seeing if that makes the problem go away?

Did that but it still crashes. The problem really must be rare. The commit in question is in for two months now and also part of a "stable" release (0.27) but I've never encountered this problem before (and I haven't seen related bug reports).

shinchiro commented 6 years ago

Tried run the sample (https://0x0.st/C26.mkv) on win10: mpv --no-config --opengl-pbo=yes --gpu-api=opengl --gpu-context=angle --fs It got crash with angle only. vulkan, win, dxinterop contexts seems fine

Related trace: https://0x0.st/srrB.txt