Bug 79520

Can you bisect Mesa?

(In reply to comment #1)
> Can you bisect Mesa?

I can, but (this sounds almost shameful to admit) I can't find which commit marks the 10.1.4 release. I bisected it at the commit 03a0471832a9d336741bca194873e8c8185245fe (it talks about adding a news item related to 10.4.1), but running LD_LIBRARY_PATH="./src/glx" LIBGL_DRIVERS_PATH="./lib/gallium/" mpv <file-name> gave me the same error.

If you can give me the requisite commit, I will bisect it at the proper place and then try this again. Not being a coder, or even someone who uses git regularly, I apologise if this is too basic a question to be asked.

(In reply to comment #2)
> I can, but (this sounds almost shameful to admit) I can't find which commit
> marks the 10.1.4 release.

The tag mesa-10.1.4 points to commit cc9b282f8a00c1d8e552a3776709ca84e1f4467d .

So I bisected mesa. The steps are:

$ make clean && make distclean

$ ./autogen.sh --prefix=/usr --sysconfdir=/etc --with-dri-driverdir=/usr/lib/xorg/modules/dri --with-gallium-drivers=r300,r600,radeonsi,swrast,svga --with-dri-drivers=r200,radeon,swrast --with-egl-platforms=x11,drm, --enable-llvm-shared-libs --enable-gallium-egl --enable-gallium-llvm --enable-gallium-gbm --enable-egl --enable-gbm --enable-shared-glapi --enable-glx --enable-glx-tls --enable-dri --enable-osmesa --enable-gles1 --enable-gles2 --enable-texture-float --enable-xa --enable-vdpau --enable-omx --enable-opencl --enable-opencl-icd--with-clang-libdir=/usr/lib && make

$ LD_LIBRARY_PATH="./src/glx" LIBGL_DRIVERS_PATH="./lib/gallium/" mpv <file-name>

for every bisection. The end result was:

ee978aee94d98fec669002eb5ef7ceb1f46683a9 is the first bad commit
commit ee978aee94d98fec669002eb5ef7ceb1f46683a9
Author: Christian König <christian.koenig@amd.com>
Date:   Mon Jul 15 09:16:22 2013 -0600

    vl: add H264 encoding interface

    Signed-off-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Leo Liu <leo.liu@amd.com>

:040000 040000 4e0bb4d3cba505fb01e24188353c3b05a4be201c 2e24ff49402d12d9865e6ef2dcb9771580bc4b8e M      src

I should add, that for every time I marked something as bad in the bisection, I would get a "zsh: segmentation fault (core dumped)" message without fail. The ones I marked as good ran perfectly.

(In reply to comment #4)
> ee978aee94d98fec669002eb5ef7ceb1f46683a9 is the first bad commit
> commit ee978aee94d98fec669002eb5ef7ceb1f46683a9
> Author: Christian König <christian.koenig@amd.com>
> Date:   Mon Jul 15 09:16:22 2013 -0600
> 
>     vl: add H264 encoding interface
> 
>     Signed-off-by: Christian König <christian.koenig@amd.com>
>     Signed-off-by: Leo Liu <leo.liu@amd.com>

This is really stange, since the patch you bisected doesn't touch any of the VDPAU or OpenGL states in question.

Can you try mesa master as well?

Thanks,
Christian.

(In reply to comment #5)
> This is really stange, since the patch you bisected doesn't touch any of the
> VDPAU or OpenGL states in question.
> 
> Can you try mesa master as well?
> 
> Thanks,
> Christian.

I just tried it with the latest master. The steps remain the same. The output was:

zsh: segmentation fault (core dumped)  LD_LIBRARY_PATH="./src/glx" LIBGL_DRIVERS_PATH="./lib/gallium/" mpv

The error number was 139.

(In reply to comment #6)
> (In reply to comment #5)
> > This is really stange, since the patch you bisected doesn't touch any of the
> > VDPAU or OpenGL states in question.
> > 
> > Can you try mesa master as well?
> > 
> > Thanks,
> > Christian.
> 
> I just tried it with the latest master. The steps remain the same. The
> output was:
> 
> zsh: segmentation fault (core dumped)  LD_LIBRARY_PATH="./src/glx"
> LIBGL_DRIVERS_PATH="./lib/gallium/" mpv
> 
> The error number was 139.

Can you get the backtrace of the segmentation fault?

(In reply to comment #7)
> Can you get the backtrace of the segmentation fault?

To get that, I'd normally have to compile mesa with CFLAGS="-g" make. Will that work here too? Or is there any other way to do it? (Sorry, I'm not a programmer myself.)

(In reply to comment #8)
> (In reply to comment #7)
> > Can you get the backtrace of the segmentation fault?
> 
> To get that, I'd normally have to compile mesa with CFLAGS="-g" make. Will
> that work here too? Or is there any other way to do it? (Sorry, I'm not a
> programmer myself.)

Instead of fiddling with the CFLAGS you should probably better use "--enable-debug" for configure.

(In reply to comment #7)
> Can you get the backtrace of the segmentation fault?

I ran it through gdb (commit number: ee978aee94d98fec669002eb5ef7ceb1f46683a9):

[vader ~/Builds/cleandir/mesa]% systemd-coredumpctl gdb
TIME                                         PID   UID   GID SIG EXE
              Wed 2014-06-04 18:44:36 JST  22401  1000   100  11 /home/vader/Builds/mpv-git/src/mpv/build/.conf_check_b4d8c0b22f0a39cf01e84c4b2bf64f50/testbuild/testprog
GNU gdb (GDB) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/vader/Builds/mpv-git/src/mpv/build/.conf_check_b4d8c0b22f0a39cf01e84c4b2bf64f50/testbuild/testprog...done.
[New LWP 22401]

warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `/home/vader/Builds/mpv-git/src/mpv/build/.conf_check_b4d8c0b22f0a39cf01e84c4b2b'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f0e85fcd452 in ?? () from /usr/lib/liblua.so.5.2

FYI if you're using VDPAU, setting LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH will not work. The libvdpau library is hardcoded to search for /usr/lib/vdpau/${driver}_vdpau.so.

There are two ways around this - rebuild libvdpau with this commit [1] and set VDPAU_DRIVER_PATH or symlink/install the library.

[1] http://cgit.freedesktop.org/~aplattner/libvdpau/commit/?id=ee9491a1216f47e10cbb551391a01c7fcde940d2

(In reply to comment #11)
> FYI if you're using VDPAU, setting LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH
> will not work. The libvdpau library is hardcoded to search for
> /usr/lib/vdpau/${driver}_vdpau.so.
> 
> There are two ways around this - rebuild libvdpau with this commit [1] and
> set VDPAU_DRIVER_PATH or symlink/install the library.
> 
> [1]
> http://cgit.freedesktop.org/~aplattner/libvdpau/commit/
> ?id=ee9491a1216f47e10cbb551391a01c7fcde940d2

I'm using the vo=opengl option in mpv.

(In reply to comment #12)
> (In reply to comment #11)
> > FYI if you're using VDPAU, setting LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH
> > will not work. The libvdpau library is hardcoded to search for
> > /usr/lib/vdpau/${driver}_vdpau.so.
> > 
> > There are two ways around this - rebuild libvdpau with this commit [1] and
> > set VDPAU_DRIVER_PATH or symlink/install the library.
> > 
> > [1]
> > http://cgit.freedesktop.org/~aplattner/libvdpau/commit/
> > ?id=ee9491a1216f47e10cbb551391a01c7fcde940d2
> 
> I'm using the vo=opengl option in mpv.

Yeah, but you are using the VDPAU hardware acceleration.

(In reply to comment #13)
> (In reply to comment #12)
> > (In reply to comment #11)
> > > FYI if you're using VDPAU, setting LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH
> > > will not work. The libvdpau library is hardcoded to search for
> > > /usr/lib/vdpau/${driver}_vdpau.so.
> > > 
> > > There are two ways around this - rebuild libvdpau with this commit [1] and
> > > set VDPAU_DRIVER_PATH or symlink/install the library.
> > > 
> > > [1]
> > > http://cgit.freedesktop.org/~aplattner/libvdpau/commit/
> > > ?id=ee9491a1216f47e10cbb551391a01c7fcde940d2
> > 
> > I'm using the vo=opengl option in mpv.
> 
> Yeah, but you are using the VDPAU hardware acceleration.

Ah. Okay, I got it. I need to leave this particular laptop right now, so I can't do that atm. I'll have it done tomorrow. Thanks for all the help and the patience.

Ok that sounds like you updated the OpenGL packages, but not VDPAU right?

Well in this case the reason it doesn't work any more is that OpenGL advertises OpenGL/VDPAU interop, but the VDPAU driver actually isn't new enough end rejects the export request.

Try the --hwdec=no option on mpv.

(In reply to comment #15)
> Ok that sounds like you updated the OpenGL packages, but not VDPAU right?
> 
> Well in this case the reason it doesn't work any more is that OpenGL
> advertises OpenGL/VDPAU interop, but the VDPAU driver actually isn't new
> enough end rejects the export request.
> 
> Try the --hwdec=no option on mpv.

You're right about that. It works perfectly with the --hwdec=no option. In the Arch repos, we have libvdpau 0.7. From what I can tell, that is the latest version out there in the wild as well.

In any case, I recompiled libvdpau from git (the current master) and installed it, but the problem persists.

Okay, after upgrading to mesa, mesa-libgl and ati-dri 10.2.1, there's been no problem. Thanks for all the help!