How can I get the _openssl.so library working on ARM64 platform?

[timusketeers]

Hi, we are using luaossl library, I want to know how can I get the _openssl.so library working on ARM64 platform? I tried using the following step, but it seems not work:

Try Steps:

1. Download the file luaossl-20181207-0.rockspec
2. Runing the following command to get the _openssl.so library:
   luarocks make luaossl-20181207-0.rockspec
3. Finally, I try use the compiled luaossl library on ARM64 platform, but there is a error "bad light userdata pointer" occurs.

Any suggestions, thanks!

[daurnimator]

Are you by chance using luajit? I know it had an issue with lightuserdata with certain addresses. Did you compile with GC64? See LuaJIT/LuaJIT#49

[timusketeers]

@daurnimator Yes，as you know, I use openresty as web container, and the author of openresty project has solved the problem in the version of openresty-1.15.8-rc1.tar.gz, the refer link is: openresty/lua-nginx-module#1019
I try to integrate _openssl.so library with it, but seems not work

[daurnimator]

What operation(s) does it fail on?

• on library load?
• when you call a certain function?
• when you use certain callbacks?

[timusketeers]

it occurs on Kong which is a opensource project whose uri link is https://github.com/kong/kong. I added some debug info, below is the error log: (when load the plugin jwt's dao, it failed)

2019/03/12 17:03:05 [error] 6245#0: *2 [lua] utils.lua:569: load_module_if_exists(): --------------kong.plugins.jwt.daos, context: ngx.timer
Error:
...loud/openresty/luajit/share/lua/5.1/kong/tools/utils.lua:577: bad light userdata pointer
stack traceback:
        [C]: in function 'error'
        ...loud/openresty/luajit/share/lua/5.1/kong/tools/utils.lua:577: in function 'load_module_if_exists'
        ...loud/openresty/luajit/share/lua/5.1/kong/dao/factory.lua:114: in function 'new'
        ...d/openresty/luajit/share/lua/5.1/kong/cmd/migrations.lua:31: in function 'cmd_exec'
        /opt/cloud/openresty/luajit/share/lua/5.1/kong/cmd/init.lua:87: in function </opt/cloud/openresty/luajit/share/lua/5.1/kong/cmd/init.lua:87>
        [C]: in function 'xpcall'
        /opt/cloud/openresty/luajit/share/lua/5.1/kong/cmd/init.lua:87: in function </opt/cloud/openresty/luajit/share/lua/5.1/kong/cmd/init.lua:44>
        ./kong:11: in function 'file_gen'
        init_worker_by_lua:50: in function <init_worker_by_lua:48>
        [C]: in function 'xpcall'
        init_worker_by_lua:57: in function <init_worker_by_lua:55>

[daurnimator]

• for "safe" functions like ssl_pushsafe and sx_custom_ext_add_cb we're going to need to split the lightuserdata into two integers for LuaJIT.
• ex_newstate/ex_hasstate is using lightuserdata as a unique key in the registry: this can probably be replaced with a masked off version.
• getctx and getbio are also using lightuserdata as a unique key in the registry; but mainly as a cache for performance reasons.
• sx_push/ssl_push first use lightuserdata as a unique key in the registry to retrieve the luaossl object cache. but then use lightuserdata to cache userdata objects (where lightuserdata pointers are used as a key to get their boxed pointer full userdata): I'm not sure how to replace this for luaJIT.

[vielmetti]

@timusketeers - it looks like it would be useful to get this new version upstreamed into kong.

[vielmetti]

and this is the relevant issue in Kong Kong/kong#4359 - I'll follow up there.