Crashes with GTK3 for the last few releases with Lua 5.1

For a while less and less of the AwesomeWM have been working for me. I am not totally sure what the issue is since it involve casting pointers to random (lua held) places and at some point things become invalid. I didn't investigate much either.

Lua 5.1, GTK3 3.24.10, GObject Introspection 1.58.3 and LGI 0.9.0

#!/usr/bin/env lua
local Gtk, class = require('lgi').require('Gtk'), 'client'
Gtk.init()
window = Gtk.Window {default_width=100, default_height=100, title='title'}
swindow.decorated = false
window:set_wmclass(class, class)
local app = Gtk.Application {}
function app:on_activate()
    window.application = self
    window:show_all()
end
app:run {''}

==1298== Memcheck, a memory error detector
==1298== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1298== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==1298== Command: lua /tmp/client.lua
==1298== 
==1298== Invalid read of size 8
==1298==    at 0x4885623: lgi_object_2lua (object.c:353)
==1298==    by 0x4885C5F: object_new (object.c:540)
==1298==    by 0x484D118: luaD_precall (in /usr/lib64/liblua.so.5.1.5)
==1298==    by 0x4857EAC: luaV_execute (in /usr/lib64/liblua.so.5.1.5)
==1298==    by 0x484D694: luaD_call (in /usr/lib64/liblua.so.5.1.5)
==1298==    by 0x484C9DD: luaD_rawrunprotected (in /usr/lib64/liblua.so.5.1.5)
==1298==    by 0x484D82C: luaD_pcall (in /usr/lib64/liblua.so.5.1.5)
==1298==    by 0x48494E7: lua_pcall (in /usr/lib64/liblua.so.5.1.5)
==1298==    by 0x1098ED: docall (in /usr/bin/lua)
==1298==    by 0x10A3B5: pmain (in /usr/bin/lua)
==1298==    by 0x484D118: luaD_precall (in /usr/lib64/liblua.so.5.1.5)
==1298==    by 0x484D663: luaD_call (in /usr/lib64/liblua.so.5.1.5)
==1298==  Address 0x4 is not stack'd, malloc'd or (recently) free'd
==1298== 
==1298== 
==1298== Process terminating with default action of signal 11 (SIGSEGV)
==1298==  Access not within mapped region at address 0x4
==1298==    at 0x4885623: lgi_object_2lua (object.c:353)
==1298==    by 0x4885C5F: object_new (object.c:540)
==1298==    by 0x484D118: luaD_precall (in /usr/lib64/liblua.so.5.1.5)
==1298==    by 0x4857EAC: luaV_execute (in /usr/lib64/liblua.so.5.1.5)
==1298==    by 0x484D694: luaD_call (in /usr/lib64/liblua.so.5.1.5)
==1298==    by 0x484C9DD: luaD_rawrunprotected (in /usr/lib64/liblua.so.5.1.5)
==1298==    by 0x484D82C: luaD_pcall (in /usr/lib64/liblua.so.5.1.5)
==1298==    by 0x48494E7: lua_pcall (in /usr/lib64/liblua.so.5.1.5)
==1298==    by 0x1098ED: docall (in /usr/bin/lua)
==1298==    by 0x10A3B5: pmain (in /usr/bin/lua)
==1298==    by 0x484D118: luaD_precall (in /usr/lib64/liblua.so.5.1.5)
==1298==    by 0x484D663: luaD_call (in /usr/lib64/liblua.so.5.1.5)
==1298==  If you believe this happened as a result of a stack
==1298==  overflow in your program's main thread (unlikely but
==1298==  possible), you can try to increase the size of the
==1298==  main thread stack using the --main-stacksize= flag.
==1298==  The main thread stack size used in this run was 8388608.
==1298== 
==1298== HEAP SUMMARY:
==1298==     in use at exit: 1,948,758 bytes in 20,509 blocks
==1298==   total heap usage: 42,381 allocs, 21,872 frees, 4,954,491 bytes allocated
==1298== 
==1298== LEAK SUMMARY:
==1298==    definitely lost: 168 bytes in 17 blocks
==1298==    indirectly lost: 0 bytes in 0 blocks
==1298==      possibly lost: 2,360 bytes in 29 blocks
==1298==    still reachable: 1,907,814 bytes in 20,131 blocks
==1298==                       of which reachable via heuristic:
==1298==                         length64           : 2,440 bytes in 37 blocks
==1298==                         newarray           : 1,808 bytes in 33 blocks
==1298==         suppressed: 0 bytes in 0 blocks
==1298== Rerun with --leak-check=full to see details of leaked memory
==1298== 
==1298== For counts of detected and suppressed errors, rerun with: -v
==1298== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
zsh: segmentation fault  valgrind lua /tmp/client.lua

It works fine with a "pure luarocks" stack created with the Lua 5.3 slot (+ LGI 0.9.2). Re-installing the system LGI (0.9.0) with the 5.1 slot brings the breakages back. It used to work fine on 5.1. I always try to use 5.1 because it is the less problematic for development (beside missing unpack declaration). Is .9 the cause or "something changed" in GObject Introspection?

Reproduce the crash with the provided Lua 5.1 GTK3 example and Valgrind output. Inspect object.c at lgi_object_2lua (line 353) and object_new (line 540), then compare the Lua 5.1 system LGI 0.9.0 setup with the working Lua 5.3/LGI 0.9.2 setup. Done means the example no longer segfaults under Lua 5.1.