Regression on May 14th build #217
Comments
|
You can try my debug build,I also use this repo to build mpv. |
|
Thanks. The package mpv-x86_64-20220514-git-d27c85b.7z has the same issue. I don't know how to make use of mpv-debug-x86_64-20220514-git-d27c85b.7z. The extracted "mpv.debug" doesn't seem to be valid exe (e.g. its import table is messed up). |
Put mpv.debug and mpv.exe in the same folder, the log I get using gdb is as follows: |
|
Thanks. Here is the call stack when seg fault: So we know it is related to fontconfig. Not sure why I wonder is the fontconfig version changed between May 13 and 14 build? |
|
I tried to revert a724e4b and build mpv with waf and this problem disappeared. Not sure why this happen but the crash only happen when building with meson. Edit: |
|
I found the problem still happens |
|
Should really fix this problem |
|
The problem persists, the gui window is still not displayed on version 20220531. |
|
Can confirm. The problem is, when I build mpv with Meson in MinGW, there is no such problem. So I'm pretty sure the issue is specific to this repo's build. Of course, my build does not have the same set of features enabled, so it could still be coming from mpv. |
|
Are you sure? I just downloaded the |
|
Don't forget you also need |
|
Hi, is this is still being worked on? Can we reopen the issue for better tracking? Thanks. |
|
@shinchiro @zhongfly I spent some time to build mpv locally (in WSL) with this repo's scripts. I can reproduce the issue locally. So I did some tests. Apparently, in MinGW, the dirent.c (which hosts The crash site at However, if I replace opendir: _wopendir: The 0x1 comes from %rsi. So it seems to me the problem comes from some kind of conflict between I think MinGW's dirent or fontconfig individually are fine, but the way this repo links them into mpv somehow messes up something, of which I don't know. I'll probably try the May 13th version, see why that build works. BTW, I know you mentioned before, in order to build this in WSL, the instruction from README.md is not enough. For example, |
|
Try revert commit a724e4b & build it. See the problem still occur or not |
|
As expected, reverting a724e4b off HEAD fixes the issue. So the meson switch is the culprit. Here is the assembly for You can see this is similar to Since all dependencies are unaffected by a724e4b, I went to compare the effective linking command from waf and Meson. Turns out, if I just replace the Meson's linking command line with waf's, the resulting exe will work! waf: Meson: The main difference here is that waf uses the I wonder if there is a way to change Meson. |
|
Try to put mpv-winbuild-cmake/packages/mpv.cmake Lines 34 to 37 in a6b3078 |
|
Doing that will put a Then, I was thinking, gcc's Finally, how to elegantly fix this? Sure, we can just add the Now, I think we have three options: 1) two |
|
Well, better create issue in mpv and linked back to this issue. Using |
shinchiro
added a commit
that referenced
this issue
Jun 15, 2022
as temporary fix for problem in #217
|
Sure: mpv-player/mpv#10293. BTW can confirm https://github.com/shinchiro/mpv-winbuild-cmake/releases/tag/20220616 (having fd4df6b) works now. |
Dudemanguy
pushed a commit
to mpv-player/mpv
that referenced
this issue
Jun 18, 2022
In win32 build, if libass and libfontconfig appear after libmingwex during linking, crash happens whenever fontconfig calls to opendir(). Moving them before ffmpeg makes sure they always appear first. More info on shinchiro/mpv-winbuild-cmake#217.
dyphire
pushed a commit
to dyphire/mpv-winbuild-cmake
that referenced
this issue
Jun 21, 2022
as temporary fix for problem in shinchiro#217
dyphire
pushed a commit
to dyphire/mpv-winbuild-cmake
that referenced
this issue
Jun 21, 2022
as temporary fix for problem in shinchiro#217
dyphire
pushed a commit
to dyphire/mpv-winbuild-cmake
that referenced
this issue
Jun 25, 2022
as temporary fix for problem in shinchiro#217
dyphire
pushed a commit
to dyphire/mpv
that referenced
this issue
Feb 22, 2023
In win32 build, if libass and libfontconfig appear after libmingwex during linking, crash happens whenever fontconfig calls to opendir(). Moving them before ffmpeg makes sure they always appear first. More info on shinchiro/mpv-winbuild-cmake#217.
dyphire
pushed a commit
to dyphire/mpv
that referenced
this issue
Feb 22, 2023
In win32 build, if libass and libfontconfig appear after libmingwex during linking, crash happens whenever fontconfig calls to opendir(). Moving them before ffmpeg makes sure they always appear first. More info on shinchiro/mpv-winbuild-cmake#217.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There seems to be a regression on May 14th build (and all builds afterwards) about fontconfig.
Steps to reproduce
mpv.exe --osd-font-provider=fontconfig --log-file=C:\mpv.logExpected result
The mpv pseduo gui window should show up.
Actual result
Nothing happens. The log file ends with
[ 0.006][v][osd/libass] Setting up fonts...Apparently, mpv.exe crashed.
%LOCALAPPDATA%\CrashDumpscontains the crash dump.Workaround
A workaround I found is that the crash seems to be caused by lack of fontconfig dir cache. If I run the command with May 13th build, populate the dir cache first, then run May 14th build, it works from then on. So far I need to keep a copy of the 13th build so that any time I install/remove a font, I run with that build once first.
Other info
May 13th build and earlier are OK. It seems the switch to meson build is not 100% equivalent.
I also built mpv myself. With both the same hash that May 14th is based on and the latest commit, it works fine. So pretty sure the upstream is not the culprit.
Is there a debug build with symbols so I could provide you crash info, in case you can't reproduce yourself?
The text was updated successfully, but these errors were encountered: