This changeset is way too complex and probably incomplete. And it doesn't solve the general issue, e.g. for 52 bit VA spaces.

lightuserdata is a legacy data type, primarily intended for the classic Lua/C API. And even there, it doesn't have many good use cases.

It's easy enough to work around the 47 bit limit. The Solaris/x64 community has had the same problem, due to their use of the negative part of the address space in user mode. Have a look what they did to change the (few) libraries that didn't play nicely:

• lightuserdata used as a unique table key, e.g. for the registry: with lua_pushlightuserdata(L, &x) and x on the C stack, replace x with a static variable.
• lightuserdata used as some kind of cross-object pointer: don't do that -- it doesn't play nicely with the GC, anyway. Replace with proper userdata references.
• lightuserdata used as a misguided userdata replacement, possibly even setting the lightuserdata metatable (ugh): throw away any such library, replace with a proper FFI binding.

Currently, we see crashes on 48-bit VA in at least :

1. LuaJIT-test-cleanup : https://github.com/LuaJIT/LuaJIT-test-cleanup/blob/master/test/misc/catch_wrap.lua
2. OpenResty core tests : https://github.com/openresty/lua-resty-core , https://github.com/openresty/test-nginx
3. wrk : https://github.com/wg/wrk

I am afraid there will be too much work if we have to do the work around in the applications.

Is it possible for us to treat lightuserdata differently and do not tag this type?

Ignore the failure in catch_wrap.lua.

The OpenResty author is pretty responsive. Just tell him the spots where lightuserdata causes trouble.

There's not a single use of lightuserdata in the current wrk codebase. Any failure must be due to something else.

Thanks for your comment!
I see wrk works on 39-bit but crashes on 48-bit. It works with the patch applied on 48-bit. So I guess there might be something wrong with the lightuserdata. We will investigate the root cause.

@MikePall After some investigation, it turns out that the failure in wrk is caused by lightuserdata use in LuaJIT itself.

I try to work around it in this pull request: #245 . Could you take a look? Thanks!

@MikePall Can we put the limitation and the way of work around somewhere publicly on the LuaJIT website? So that it will be much easy for the users to fix the issue themselves.

lightuserdata used as a unique table key, e.g. for the registry: with lua_pushlightuserdata(L, &x) and x on the C stack, replace x with a static variable.

Will this work with lua_cpcall? It's good practice to allocate a struct on the stack and pass it through from a library callback (where you shouldn't longjmp out) by using lua_cpcall. To use a static variable to work around this would not only be bad code, but break re-entrancy.

We can also store the address in string to solve this problem, although there will be some performance loss, but
Usually, the address of most aarch64 devices does not exceed 47bits, we can still use lua_pushlightuserdata normally.

My workaround implementation:

 static __tb_inline__ tb_void_t xm_lua_pushpointer(lua_State* lua, tb_pointer_t ptr) 
 { 
     tb_uint64_t ptrval = (tb_uint64_t)ptr; 
     if ((ptrval >> 47) == 0) 
         lua_pushlightuserdata(lua, ptr); 
     else 
     { 
         tb_char_t str[64]; 
         tb_long_t len = tb_snprintf(str, sizeof(str), "%p", ptr); 
         lua_pushlstring(lua, str, len); 
     } 
 } 

The full implmentation:

https://github.com/xmake-io/xmake/blob/96b0eae26058482a83f5bbf57bab15a834339464/core/src/xmake/prefix.h#L36-L83

We can also store the address in string to solve this problem, although there will be some performance loss, but
Usually, the address of most aarch64 devices does not exceed 47bits, we can still use lua_pushlightuserdata normally.

The main point of a lightuserdata instead of a full userdata is that the allocation of one cannot fail (lua_pushlstring can fail).

Resolved in a different way.