On Wed, Jun 16, 2021 at 07:08:52AM +0300, srfsh wrote:
> To ports@openbsd.org <sr...@sonu.ch> wrote:
> > Sebastien Marie <sema...@online.fr> wrote:
> > > the library to use in LD_PRELOAD will depend of the gpu. on mine
> > > system, it is radeonsi_dri.so for example.
> > >
> > > you could try with LD_DEBUG=1 to see the ld.so activity:
> > >
> > > $ LD_DEBUG=1 mpv --vo=gpu file.mp4
> > > [...]
> > > (+) Video --vid=1 (*) (h264 640x360 25.000fps)
> > > (+) Audio --aid=1 (*) (aac 2ch 48000Hz)
> > > tib new=0x790502c1000
> > > dlopen: loading: /usr/X11R6/lib/modules/dri/radeonsi_dri.so
> > > flags /usr/X11R6/lib/modules/dri/radeonsi_dri.so = 0x0
> >
> > Thanks for the information. It works for me with radeonsi_dri.so too.
>
> Okay, little bit late response but I discovered this very recently.
> Let me explain: I run an unwind(8) instance on my computer where I
> blacklist a very long list of hosts (such as www.youtube.com). The
> thing is, when I try to access www.youtube.com through torsocks(1) and
> tor(1) (such as with mpv(1)), I expect everything (including DNS
> queries) to go through the tor network, but when I have LD_PRELOAD set,
> mpv(1) just tells me this:
>
> [ffmpeg] tcp: Failed to resolve hostname www.youtube.com: no address
> associated with name
I think that torsocks is diverting syscalls with LD_PRELOAD. so
depending how you call it, you might override the LD_PRELOAD setted by
torsocks.
> This is exactly what happens when I try to query a blacklisted hostname
> through unwind(8). When I don't have LD_PRELOAD set, though, it just
> works as expected (that is, www.youtube.com is queried through the tor
> network). I'm sorry I realized this a little late, but this method has
> an issue like this, so I wanted report as soon as possible. I'm on
> -current, by the way.
the "method" you mentioned isn't a way to resolv the problem. it was a
way to properly diagnostic the problem: something inside
radeonsi_dri.so (exactly emutls) which cause segfault when the library
is unloaded. using LD_PRELOAD permitted to unsure that forcing the
library to stick correct the problem.
if you want alternate ways to fix/workaround the problem:
- provide a patch with proper TLS support
- provide a patch for emuTLS for avoiding unloading a library when emuTLS is
from library
- use another video output (mpv --vo=sdl ...)
- ignore the core file and/or disable the coredump generation (with a wrapper):
#!/bin/sh
ulimit -c 0
exec /usr/local/bin/mpv "$@"
Thanks.
--
Sebastien Marie
