Change:
<ins> { stdenv , fetchFromGitHub }: stdenv.mkDerivation rec { pname = "simple-mpv-ui"; version = "1.0.0"; src = fetchFromGitHub { owner = "open-dynaMIX"; repo = "simple-mpv-webui"; rev = "v${version}"; sha256 = "1glrnnl1slcl0ri0zs4j64lc9aa52p9ffh6av0d81fk95nm98917"; }; dontBuild = true; installPhase = '' mkdir -p $out/share/mpv/scripts cp -r webui.lua webui-page $out/share/mpv/scripts/ ''; passthru.scriptName = "webui.lua"; meta = with stdenv.lib; { description = "A web based user interface with controls for the mpv mediaplayer"; homepage = "https://github.com/open-dynaMIX/simple-mpv-webui"; maintainers = [ maintainers.cript0nauta ]; longDescription = '' You can access the webui when accessing http://127.0.0.1:8080 or http://[::1]:8080 in your webbrowser. By default it listens on 0.0.0.0:8080 and [::0]:8080 ''; license = licenses.mit; }; } </ins>

Discussion:
Describe the bug When mpv is compiled with samba support, running mpv with a script that uses luasocket will trigger a segmentation fault. This happens because both luasocket and samba export symbols with the same name (such as and ). When the luasocket C code attempts to call its own functions, it will end up calling samba functions. This will obviously crash. If I override mpv with it works ok, but I'm not sure if disabling samba support is desired. To Reproduce Steps to reproduce the behavior: the following script and save it into : Expected behavior A clear and concise description of what you expected to happen. Running the previous command should produce the following output: instead of crashing with a segmentation fault. Additional context To test this bug it is required to use a nixpkgs version that has the commit . Otherwise, mpv won't be able to import luasocket. Samba support for mpv is enabled in Linux systems. Therefore, this issue doesn't exist in darwin systems. Notify maintainers Metadata Maintainer information:
Looks like an upstream bug: using libraries with conflicting symbols. In fact, I have Googled it and got this:
Interesting suspicion, but I I don't understand how you reached this conclusion - the wrapper has in the environment and while samba's symbols are supposed to be linked "hardly" as reported by - without any relation to the environment. The wrapper makes mpv run with and containing both the user's (if already set) search directories and the luasocket and lua search paths that were used in the build of mpv. Initially, I had the suspicion that if I'll unset my own and environment, and let only the wrapper's environment influence it won't segfault, but I was wrong, it still segfaults. I think that the original intention behind the wrapper's adding this to the environment: Was to make everyone be able to write Lua scripts that load luasocket, and indeed without this environment (and without it being preset in the environment), loading that example script fails due to unfound , as expected. Anyway, I tend to think this is indeed an upstream issue. I tried to investigate it with gdb but I didn't manage to figure out what's going on after I :
I had the same problem with gdb.

The problem was that the mpv executable is not an ELF binary, but a shell script wrapping it. I set the wrapped environment variables inside my shell: and then ran gdb to the .mpv-wrapped, that is the actual ELF binary: The backtrace indicates that luasocket's function is called, and then it calls libsamba's . I guess that tried to call luasocket's but libsmba's was called instead. I don't have any idea why this might be happening.
Well done on getting that stack trace :+1:, I thought I managed to run gdb on the unwrapped executable but I guess I was wrong... I think this should be reported upstream.
I thought in reporting it to upstream, but it seems only nixpkgs' mpv is affected. I tested this in Debian Buster, Xubuntu 20.04 and Arch Linux. All of them use libsamba and show the message, so I suspect the problem is in nixpkgs itself and not in the upstream version. This is a good observation and could give a hint on the bug. It is strange that luasocket, which doesn't depend on libsamba, confuses its own functions with libsamba's functions.
Can you try and test this when the luasocket rock is installed in a non default location and you use and pointing to that location?
Maybe when calling the binaries the link resolution is solved in a certain order while the ordering in NixOS is not always the same.
Ok, I've been able to reproduce the problem using Arch Linux and luarocks by running: I didn't have to set nor because luasocket it is installed in the default location. If I install the package instead of using luarocks, the script runs successfully. Now I'm going to compare both versions to see why is the luarocks versions failing.
I can now confirm that the problem only exists when using the luarocks version of luasocket. Using the GitHub version of luasocket, as we did before commit , fixed the issue. I'll prepare a PR reverting part of that commit so we can have mpv with both libsamba and luasocket working properly