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

wahern / luaossl

Most comprehensive OpenSSL module in the Lua universe.

http://25thandclement.com/~william/projects/luaossl.html

Other

142 stars 48 forks source link

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

Closed timusketeers closed 5 years ago

timusketeers commented 5 years ago

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:

Download the file luaossl-20181207-0.rockspec
Runing the following command to get the _openssl.so library: luarocks make luaossl-20181207-0.rockspec
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 commented 5 years ago

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

timusketeers commented 5 years ago

@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: https://github.com/openresty/lua-nginx-module/issues/1019 I try to integrate _openssl.so library with it, but seems not work

daurnimator commented 5 years ago

What operation(s) does it fail on?

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

timusketeers commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

vielmetti commented 5 years ago

and this is the relevant issue in Kong https://github.com/Kong/kong/issues/4359 - I'll follow up there.