Bad argument #1 to 'registerlock' (userdata expected, got nil)

[MattiaSilvestri]

Output of awesome --version:

awesome v4.3-1066-g832483dd6 (Too long)
 • Compiled against Lua 5.3.6 (running with Lua 5.3)
 • API level: 4
 • D-Bus support: yes
 • xcb-errors support: no
 • execinfo support: yes
 • xcb-randr version: 1.6
 • LGI version: 0.9.2
 • Transparency enabled: yes
 • Custom search paths: no

How to reproduce the issue:
Install gtk4 through system upgrade (Manjaro Linux). Other packages were installed, but I read that gtk4 is incompatible with LGI so I think that package is the origin of the error.

Actual result:
When I login into the awesome session, the default configuration is loaded and I get a red window with the following error message:
/usr/share/lua/5.3/lgi/override/Gdk.lua:23: bad argument #1 to 'registerlock' (userdata expected, got nil)

Expected result:
My personal config should be loaded and awesome should work as usual even with gtk4.

Comments: I'm not an expert and I don't know what LGI is. I'm not even sure whether I already had gtk4 installed and an update to the package caused awesome to break, or whether gtk4 was actually installed for the first time during the upgrade and this caused the error.

[sclu1034]

This is an upstream issue.
See lgi-devs/lgi#226.

Since that issue exists for more than 2 years now, and this is the second time I heard this from a Manjaro user recently, it's most likely caused by a change in Manjaro.

[MattiaSilvestri]

@sclu1034 I also found the issue you mentioned, but it didn't seem to provide any solution I was able to implement. Does this mean I cannot use awesome with Manjaro? Or maybe I can but I need to do some complex hack in the lua files?

[sclu1034]

You cannot use LGI, or any project that depends on it, with GTK4.
Whether you can use Awesome with Manjaro depends on whether you can configure Manjaro's use of GTK4 in a way that it becomes compatible with LGI. And given that this issue only appeared within the last few days/weeks, it seems to be caused/affected by a recent change in Manjaro.

The maintainers of LGI may be able to help, or the people on the Manjaro forums. But to Awesome, this is an upstream issue and I don't see any way to "hack around it" in Awesome's Lua config.

[swiftgeek]

@MattiaSilvestri @sclu1034 then as workaround you can choose to not use gtk4 - specify version with lgi.require

(Not using awesomewm, but stumbled upon similar issue in chdkptp, see lgi-devs/lgi#269 )

@actionless you might want to reopen

[actionless]

i'm using arch linux and have both gtk3 and gtk4 installed and after merging https://github.com/awesomeWM/awesome/pull/3297/files the problem disappeared

could be smth manjaro-specific then

[zhisme]

Had the same issue today when application nautilus recently updated to use gnome-desktop-4 and gtk4

awesome --version
awesome v4.3-1360-gc539e0e43 (Too long)
 • Compiled against Lua 5.4.4 (running with 0.9.2)
 • API level: 4
 • D-Bus support: yes
 • xcb-errors support: no
 • execinfo support: yes
 • xcb-randr version: 1.6
 • LGI version: /usr/share/lua/5.4/lgi/version.lua
 • Transparency enabled: yes
 • Custom search paths: no

is there workaround to use gtk4 and gtk3 both installed in os and still using awesomewm?
https://github.com/awesomeWM/awesome/pull/3297/files this one didn't helped me, still received the error.

[MattiaSilvestri]

@zhisme for me what it worked was modifying all the files described here: lgi-devs/lgi#226 (comment)
I opened the commit and manually perform all the modification indicated there, hope it helps.

[sclu1034]

To re-iterate:
This is an upstream issue that cannot be fixed or worked around in AwesomeWM (beautiful/gtk.lua being the one exception that's been fixed for a year now).
You need the LGI devs to fix this, and they merged lgi-devs/lgi#273 for that. If you still get the above error message, even with LGI built from the newest source, you'll have to tell them at https://github.com/lgi-devs/lgi/issues.

[actionless]

i think the problem is old LGI version being installed (also very weird output of awesome -v btw)

[Frityet]

Seeing as lgi hasn't been updated in years now (5 years on luarocks), will the fix here be pushed to a fork?

[actionless]

Seeing as lgi hasn't been updated in years now

wut?

[dyfrgi]

lgi dev has not had a new release since 2017, and development has been mostly at a halt for longer.

For releases, this is the case both on Luarocks (https://luarocks.org/modules/pavouk/lgi) and in package managers. As a result, to build AwesomeWM, one now also has to install lgi manually - can't use luarocks, can't use apt.

beautiful/gtk.lua works around this by explicitly loading Gtk 3.0. Could this be done for other places where Gtk is loaded?

If this can't be worked around by changing AwesomeWM code, at least we should update the AwesomeWM docs to say that you need to install lgi from git, and saying how to do so.

lgi-devs/lgi#305 added a rockspec allowing building from the git repo.

luarocks install https://raw.githubusercontent.com/lgi-devs/lgi/master/lgi-scm-1.rockspec

[actionless]

for other places where Gtk is loaded

which places?

[Aire-One]

Hello @dyfrgi, I think there are some confusions that need to be clarified here:

LGI is a GObject bindings using GObject-Introspection. Basically, its role is to allow Lua code to interact with external code from other applications that expose the appropriate interfaces. We can mention here GLib and Cairo that Awesome uses as its core libraries.

→ As a user, you need to manually build LGI from source only if you want to use Lua5.4 (BTW, Awesome supports Lua5.4 only when building from source). Otherwise, (when using Lua5.1 to Lua5.3 and LuaJIT) you should stick to the LGI distributed by your package manager.

GTK is a lib Awesome can interact with thanks to LGI. The migration from GTK 3 to GTK 4 introduced a lot of breaking changes. They need to be taken care at LGI first, then it will reverb to the Awesome codebase. As a workaround, Awesome forces the usage of GTK 3. → As a user, there is nothing you have to do (maybe you need to install GTK 3, but most likely you already have it because a lot of software still have it as a dependency (including Awesome)).

Because nobody had the will to write the new code (and as you mentioned: as a user you can still use GTK 3, so no one is forced to complete the migration), the support of GTK 4 in LGI is still in an unknown status lgi-devs/lgi#278.

[dyfrgi]

which places?

Seems like some of the tests load it, on my system - running make check produces a bunch of errors about registerlock. Ran into it while working on #1816.

The final binary seems to run fine, though, so perhaps this is a test-only issue. I'd still like a way to run all the tests to pass, though. Perhaps I should open a separate issue for that problem. Doing a quick search, it looks like tests/test-selection-watcher.lua, tests/test-selection-transfer.lua, and tests/test-selection-getter.lua load Gtk without setting a version. I'll try changing those and send a PR if it works.

@Aire-One Thanks for the extra explanation! Is Awesome forcing GTK 3 just via lgi.require('Gtk', '3.0') or is there some other mechanism as well?

[actionless]

ah, i wasn't thinking about the tests - then yup, feel free to PR that fix indeed

[actionless]

Is Awesome forcing GTK 3 just via lgi.require('Gtk', '3.0') or is there some other mechanism as well?

read a bit abot GObject Introspection, basically lgi gives support for GI - and GI itself knows Gtk3, Gtk4, Gstreamer and other glib-based libs which spport GI

version check could be forced in cmake - but it's an optional dependency, so it won't be

also when packaging for repository - the packager could add GTK>3,<4 to optional dependencies