Segmentation fault on CentOS #139
Comments
|
This is is most likely a build/installation problem, no? Anybody care to explain what's so different about CentOS that would cause LuaSocket to crash? I don't have access to a CentOS machine. |
|
The problem was occurring when I was requiring luasocket inside of a function like: local function test()
local tcp = require("socket").tcp()
endWhen moving the require outside of the function, everything works well: local socket = require("socket")
local function test()
local tcp = socket.tcp()
end |
|
May be you get segmentation fault when close lua_State? |
|
What version of Lua are you using? During a "lua_close", Lua should GC all objects in the reverse order they are "created". So this wouldn't be a problem. Second, Lua should keep a reference to the library in the _LOADED table, so it won't be collected even though you didn't keep a reference to it. This is very strange. |
|
I was using Lua |
|
Is this problem still occurring? Is there anything we can do to reproduce the problem or troubleshoot it further? We're reviewing open items in preparation for a release. If action is needed here, please add a comment. Otherwise, this issue will be closed on or after 24-Feb-2019. Thanks! |
|
My OS is Linux amzn2.x86_64, which is basically centos7. i get segmentation fault from the following code: The segfault backstrace: Also tried it on pure cenos7 on docker env using: the weird thing is that if i remove the require of pcre, the problem doesnt happen .. |
|
Seems like luasocket is importing buffer_init from rex_pcre2. This shouldn't happen. Both libraries are wrong in that they are exporting or importing a symbol that has a very common name and has not been decorated by the library name. LuaSocket itself doesn't need to import the symbol. But I thibk LuaSec uses it and that's why we can't change it unilaterally or stop exporting it. Either way, something would crash. |
|
I see, but how come it doesn't happen in centos 6 ? |
|
Unable to reproduce on fresh amzn2-ami-hvm-2.0.20190115-x86_64-gp2 with lrexlib-pcre2 installed via luarocks and current LuaSocket master. |
|
Depends on the order, yes. I'm not familiar with the rules. But it's a disaster waiting to happen. It also depends on how lrexlib-pcre2 is compiled. Maybe it doesn't need to export that symbol at all? |
|
My understanding is that object names need to be known to the linker at build time in order to collide. That would mean that any namespace collision between these two packages would have to actually be related to a third library they both link against. Am I misunderstanding? To test my understanding, I've put the following code in two different test builds: Except that in the second one I assigned Lua is happy enough to treat them entirely separately. I suspect this is crash is more nefarious, and involves a third library that both packages happen to use. Am I misunderstanding something? But first it would be really great to be able to reproduce it at will. Without that, we're all kind of just speculating. Unless we can track down what line of code is in the chain at Also, can the OP please confirm that you are using LuaSocket master. |
|
It happens in function named: tcp_create: |
|
How are you building LuaSocket? For that to happen, I would think that LuaSocket must be accidentally linking against rex_pcre2.so somehow. In other words, I'd expect your version of this: to show |
|
Nope, doesnt look like its linked with rex_pxre2.so. |
|
What about this: |
|
Even with dlopen it would happen. I think. |
|
|
For functions the linker finds in a dynamic library, |
So it doesnt look like buffer_init is a dynamic symbol .. Mmm.. |
|
Since we're otherwise stumped right now, maybe an experiment is in order. What if you did in your LuaSocket build directory. @diegonehab, the LuaSec project imports our C files into their build tree wholesale, so I don't think it's possible for us to break them without changing our Lua-facing API. No? |
|
i put a breakpoint in tcp_create, and search for buffer_init functions, found 2 function, as expected .. As we can see, the first one belongs to the pcre lib, so i guess it picks the first one and goes with it. |
|
I still want to know what's really going on, but I've pushed #269 with all of the e.g. |
|
Confirmed that LuaSec still works with above change applied. |
|
If LuaSec doesn't need these functions, then there is no need to change the prefix. Let's simply stop exporting them. Right? This way the linker will resolve them locally. |
|
Fun idea. In theory, I think the only functions that should really need to be externally visible are the In Windows we need the converse of It might not help us here, where we need to avoid using other libraries' exported functions. But as a principle of least exposure I really like it anyway. Investigating further. |
|
Wait. I thought we compiled with visibility hidden already. No? Maybe this is the problem. The distribution isn't doing the same. |
|
You're right, we do. But I still see them. Also the makefile doesn't do |
|
I just gained access to my computer. (I am in transit at the moment.). The symbols read as local to the library here in my computer diego@descartes:~/impa/luasocket/src {master}$ nm socket-3.0-rc1.so | grep buffer So I don't know what is going on. Can you run the same command in the shared library you have in your system, @galtet ? |
|
|
So, for my understanding, buffer_init in my case is a global function (T), and in your case its not global (t), na ? |
|
Exactly. I don't know what changed in the build system used in your platform, but they don't appear to be building with fvisibility=hidden. Can you investigate? |
seems like |
|
Did they patch buffer.c to add one of the LUASOCKET_API prefix to the function declarations? |
|
they == centos 7 ? |
|
Yes. If they are compiling with hidden and yet the symbols are not hidden, the only thing that comes to mind, other than an unlikely compiler bug, is that they used an attribute in the buffer functions, just like we use for luaopen_socket. |
|
Something interesting .. when installing with luarocks, i get: and when checking the .so file after So it means that something it happening during the luarocks installation =/ |
|
@ewestbrook, any idea? Maybe luarocks has some other package that wants to use buffer_* functions and that's why they are exporting the symbols? Very strange. I don't know much about luarocks, but I couldn't find anything obvious that would cause this in a cursory search. |
|
Ok, so it seems to be the problem. when installing it locally without luarocks, and pcre with luarocks, everything is ok, but when installing luasocket with luarocks, i get the segfault again. so its something with luarocks and centos7 .. |
|
And indeed, it also seems that luarocks compiles the rock without the hidden flag, for example: and this is how luarocks compiles it: And this is luarocks output whemn installing the rocks: Ignore the warning at the end of the log, it because i previously installed it locally .. |
|
So this seems to solve the problem. Somehow, the flag went missing along the way. I guess we could ask them to patch the rock and add the missing flag. :) |
I am not a big luarocks expert, but they compile it differently than the way i compiled it locally ? |
|
Me neither. But this would appear to be the situation. :( |
|
out of curiosity, why don't you use build.type = make ? instead of build.type = builtin in the rockspec ? |
|
Great news! But before we celebrate... @galtet, can you confirm that you get the original segfault only when running LuaSocket from LuaRocks? I was under the impression you had encountered the crash with current git master, which LuaRocks isn't. Obviously LuaRocks must feel the default for As for LuaRocks But, as we see here, LuaRocks So I'm inclined to add "don't export" directives on the functions in the actual code, rather relying on the makefile or gcc comand line. In other words, marking all functions that are not marked |
|
Yes, confirmed. only when i install it using luarocks. otherwise, i use the makefile and its ok. |
|
Maybe use instead? |
|
Working on it now. Can confirm so far that building a "rock" for LuaRocks with Will experiment with More to follow. |
|
Unfortunately, Windows doesn't seem to have a similar |
|
It's the default on Windows. The only symbols that get exported are the ones marked with dllexport. |
|
Makes sense. Applying the |
|
Cool, thanks a lot ! When does a new release of luasocket will be out and available through luarocks ? |
On CentOS 7 I experience a
segmentation faulterror when executing:You can try with docker in interactive mode:
$ docker run -ti centos:7 /bin/bashThe text was updated successfully, but these errors were encountered: