Crash on recent GLib/libffi versions

[Rihcus]

Dependency issues with linuxwiimote on manjaro

Installed Dependencies:

I am not sure where libffi.so.6 is supposed to come from

[v1993]

I think the problem here is that some recent distributives (like Ubnuntu 20.10 and seemingly Manjaro, but not Ubuntu 20.04, where package is built) ship with libffi.so.7, the newer version of shared library. I don't yet have a proper solution to this problem (other than potentially dropping Ubuntu 20.04 LTS support). A workaround would be to build lgi module from luarocks manually on your machine, but that could be tricky for unprepared users.

[Rihcus]

I did install the lgi module via install-luadeps.sh, which does mention building lgi from git wouldn't that work? I did install lgi from luarocks earlier so I don't know if that impacted the run.

git clone https://github.com/pavouk/lgi.git cd lgi make rock luarocks make --tree "$DEPSDIR" lgi-*.rockspec cd ..

Would it be theoretically possible to make a appimage release or flatpak build?

[Rihcus]

creating a symlink between libffi.so.6 and libffi.so.7 seems to do the trick

sudo ln -s /usr/lib/libffi.so.7 /usr/lib/libffi.so.6

Edit this only seems to work for the autocallibrrate. The main script fails

[v1993]

I suspect you haven't defined $DEPSDIR variable while installing lgi, have you? Also, you must use luarocks version for Lua 5.3, or it won't work and cause a bunch of weird issues.

If you want to install lgi module yourself, do the following (delete symlink to library first):

1. Make sure you have luarocks for Lua 5.3. To check it, run luarocks config lua_version, it must output 5.3. If not, you'll probably have to install luarocks from sources (again, make sure to configure it for Lua 5.3 during installation).
2. Run code below:

   export DEPSDIR=/path/to/linuxmotehook/deps # Insert correct path here
   git clone https://github.com/pavouk/lgi.git
   cd lgi
   luarocks make --tree "$DEPSDIR" lgi-*.rockspec

   (use ``` to create code blocks like that)

I'm not sure about flatpak (probably would be doable but rather tricky), but appimage wouldn't work well, since my program is in Lua and consists of multiple files. It also have two user-end programs (autocalibrator and main script). Generally, AppImage isn't a very good option for terminal programs anyways.

P.S.: just curious, what error did running main program produced? Something complicated about missing symbols?

[Rihcus]

WiiMote successfully registered (MAC 0x0005057E0306)
Lgi:ERROR:marshal.c:1197:lgi_marshal_2c_caller_alloc: assertion failed: (size > 0)
Bail out! Lgi:ERROR:marshal.c:1197:lgi_marshal_2c_caller_alloc: assertion failed: (size > 0)

that was the symlink error

[gnulabis]

Hi @Rihcus , @v1993 , I'm on Archlinux, and while trying to setup linuxmotehook, I came across exactly the same error when trying to run main.lua:

WiiMote successfully registered (MAC 0x0005057E0306)
**
Lgi:ERROR:marshal.c:1177:lgi_marshal_2c_caller_alloc: assertion failed: (size > 0)
Bail out! Lgi:ERROR:marshal.c:1177:lgi_marshal_2c_caller_alloc: assertion failed: (size > 0)
Aborted (core dumped)

Any idea to get me started with debugging this?

[v1993]

@gnulabis This is caused by library version mismatch. You must not softlink libffi, build lgi module yourself instead.

[gnulabis]

Thanks @v1993 , for the quick reply.

However, in my case, I never softlinked libffi.

It was not necessary because nothing was complaining about libffi6.

$ ls -l /usr/lib*/libffi*
lrwxrwxrwx 1 root root    15 Apr  8  2020 /usr/lib32/libffi.so -> libffi.so.7.1.0
lrwxrwxrwx 1 root root    15 Apr  8  2020 /usr/lib32/libffi.so.7 -> libffi.so.7.1.0
-rwxr-xr-x 1 root root 38216 Apr  8  2020 /usr/lib32/libffi.so.7.1.0
lrwxrwxrwx 1 root root    15 Oct 15 22:56 /usr/lib64/libffi.so -> libffi.so.7.1.0
lrwxrwxrwx 1 root root    15 Oct 15 22:56 /usr/lib64/libffi.so.7 -> libffi.so.7.1.0
-rwxr-xr-x 1 root root 42960 Oct 15 22:56 /usr/lib64/libffi.so.7.1.0
lrwxrwxrwx 1 root root    15 Oct 15 22:56 /usr/lib/libffi.so -> libffi.so.7.1.0
lrwxrwxrwx 1 root root    15 Oct 15 22:56 /usr/lib/libffi.so.7 -> libffi.so.7.1.0
-rwxr-xr-x 1 root root 42960 Oct 15 22:56 /usr/lib/libffi.so.7.1.0

And I installed the lgi module from luarocks, which seems to build the module in the process:

$ luarocks --lua-version 5.3 install lgi
Installing https://luarocks.org/lgi-0.9.2-1.src.rock

lgi 0.9.2-1 depends on lua >= 5.1 (5.3-1 provided by VM)
make -C lgi
make[1]: Entering directory '/tmp/luarocks_lgi-0.9.2-1-wEL2lt/lgi/lgi'
pkg-config --exists 'gobject-introspection-1.0 >= 0.10.8' --print-errors
touch .depcheck
gcc -fPIC  -O2 -fPIC -I/usr/include/lua5.3 -I/usr/include/gobject-introspection-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread  -Wall -Wextra -O2 -g -c -o buffer.o buffer.c
gcc -fPIC  -O2 -fPIC -I/usr/include/lua5.3 -I/usr/include/gobject-introspection-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread  -Wall -Wextra -O2 -g -c -o callable.o callable.c
gcc -fPIC  -O2 -fPIC -I/usr/include/lua5.3 -I/usr/include/gobject-introspection-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread  -Wall -Wextra -O2 -g -c -o core.o core.c
gcc -fPIC  -O2 -fPIC -I/usr/include/lua5.3 -I/usr/include/gobject-introspection-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread  -Wall -Wextra -O2 -g -c -o gi.o gi.c
gcc -fPIC  -O2 -fPIC -I/usr/include/lua5.3 -I/usr/include/gobject-introspection-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread  -Wall -Wextra -O2 -g -c -o marshal.o marshal.c
gcc -fPIC  -O2 -fPIC -I/usr/include/lua5.3 -I/usr/include/gobject-introspection-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread  -Wall -Wextra -O2 -g -c -o object.o object.c
gcc -fPIC  -O2 -fPIC -I/usr/include/lua5.3 -I/usr/include/gobject-introspection-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread  -Wall -Wextra -O2 -g -c -o record.o record.c
gcc -shared  -o corelgilua51.so buffer.o callable.o core.o gi.o marshal.o object.o record.o -lgirepository-1.0 -lgobject-2.0 -Wl,--export-dynamic -lgmodule-2.0 -pthread -lglib-2.0 -lglib-2.0 -L/usr/lib/../lib -lffi 
echo "return '0.9.2'" > version.lua
make[1]: Leaving directory '/tmp/luarocks_lgi-0.9.2-1-wEL2lt/lgi/lgi'
make -C lgi install
make[1]: Entering directory '/tmp/luarocks_lgi-0.9.2-1-wEL2lt/lgi/lgi'
mkdir -p /usr/lib/luarocks/rocks-5.3/lgi/0.9.2-1/lib/lgi
cp corelgilua51.so /usr/lib/luarocks/rocks-5.3/lgi/0.9.2-1/lib/lgi
mkdir -p /usr/lib/luarocks/rocks-5.3/lgi/0.9.2-1/lua
cp ../lgi.lua /usr/lib/luarocks/rocks-5.3/lgi/0.9.2-1/lua
mkdir -p /usr/lib/luarocks/rocks-5.3/lgi/0.9.2-1/lua/lgi
cp class.lua component.lua core.lua enum.lua ffi.lua init.lua log.lua namespace.lua package.lua record.lua version.lua /usr/lib/luarocks/rocks-5.3/lgi/0.9.2-1/lua/lgi
mkdir -p /usr/lib/luarocks/rocks-5.3/lgi/0.9.2-1/lua/lgi/override
cp override/cairo.lua override/Clutter.lua override/Gdk.lua override/Gio-DBus.lua override/Gio.lua override/GLib-Bytes.lua override/GLib-Error.lua override/GLib.lua override/GLib-Markup.lua override/GLib-Source.lua override/GLib-Timer.lua override/GLib-Variant.lua override/GObject-Closure.lua override/GObject-Object.lua override/GObject-Type.lua override/GObject-Value.lua override/GooCanvas.lua override/Gst.lua override/Gtk.lua override/PangoCairo.lua override/Pango.lua /usr/lib/luarocks/rocks-5.3/lgi/0.9.2-1/lua/lgi/override
make[1]: Leaving directory '/tmp/luarocks_lgi-0.9.2-1-wEL2lt/lgi/lgi'
lgi 0.9.2-1 is now installed in /usr (license: MIT/X11)

Furthermore, I downloaded myself the lgi sources and tried a few of the examples in the samples directory, they all seem to work fine.

As a last note, the actual behavior is that when I run main.lua, it starts ok, I get the message that the WiiMote is registered and it crashes only when I start CEMU, or if I run PadTest and click on "start" button.

[v1993]

@gnulabis That's weird, to say the least. Have you tried removing lgi version that ships with linuxmotehook?

[gnulabis]

@v1993 , I cloned the repo from github, so I did not get the "bundle" and no deps with it. That's why I did not encounter the libffi6 issue like @Rihcus I guess. Is there something I can do to produce a more informative output than the simple assertion error?

[v1993]

@gnulabis I'm afraid you'll have to dig into lgi source code to debug this further. One last thing to try first: install lgi from git repository instead of luarocks, see CI scripts on how to do this. It may be fixed in git but not in release.

EDIT: here's how to install:

git clone https://github.com/pavouk/lgi.git
cd lgi
make rock
luarocks make lgi-*.rockspec

[gnulabis]

lgi from the git repo did not help, the error is the same.

I started looking at the sources, here's what I've found so far:

The error is coming from lgi/marshal.c, in function lgi_marshal_2c_caller_alloc() at line 1197: https://github.com/pavouk/lgi/blob/d10a9b91aa79f148681963445880ceec5af4f684/lgi/marshal.c#L1197

And the assert is failing there because the GITypeInfo *ti that we pass to g_type_info_get_array_fixed_size (ti) is an array indeed, but not of fixed size, so the function returns -1. On the other hand, I tried calling g_type_info_get_array_length(ti) and that one returns 2.

This function, lgi_marshal_2c_caller_alloc(), is called in turn from lgi/callable.c, in function callable_call() at line 895: https://github.com/pavouk/lgi/blob/d10a9b91aa79f148681963445880ceec5af4f684/lgi/callable.c#L895

So, it seems that at some point we are passing an array from Lua to C that is not of fixed size, and lgi does not like that.

@v1993 , do you have any idea/suspicion as to why suddenly in my installation (and @Rihcus ) we are passing a non-fixed length array while in yours it clearly does not happen (otherwise the lgi code would have asserted)?

edit: or, perhaps you can help me figure out how to find out what it is exactly this array that we are allocating space for? Is there a way to see some more info about the Lua object (such as name, contents) by modifying the lgi sources? My Lua and gobject knowledge is extremely limited to figure this out on my own.

[v1993]

@gnulabis I'm also mostly clueless here. I suspect something have changed in libffi or other external library, but not sure what exactly have happened.

I'll try reproducing this locally (previous times I didn't actually tried using connecting to linuxmotehook, not reaching the crash).

[v1993]

Please continue discussion of relevant crash in https://github.com/pavouk/lgi/issues/265. I'll leave this issue open until it's fixed and build with fix is released.

[gnulabis]

Many thanks!

[cipitaua]

Hello, is there any way to circumvent this bug? For example by installing a previous version of libffi? Thank you.

[v1993]

@cipitaua I simply don't know. In theory, it may work if you'll use "bundled" package from this repository and get yourself libffi6, but I can't promise anything.

[v1993]

For anyone who comes across this issue: I'm currently looking into rewriting linuxmotehook in another language, which will allow to get rid of this issue (and hopefully simplify further development and distribution too). You also can try out https://github.com/joaorb64/xwiimote-cemuhook, which tries to be a bit more invasive than linuxmotehook, but also includes its functions.

[v1993]

Please see linuxmotehook2 for successor to this project.