Segmentation Fault

[lipp]

I know segmentation faults are improbable (not possible) for lua-only modules, but here is what I am observing with 9c221c4:

https://travis-ci.org/lipp/lua-websockets/builds/7674777

This does not happen with busted 1.9.0 from Luarocks repo :
https://travis-ci.org/lipp/lua-websockets/builds/7729683
(I know it is failing anyhow...)

[Tieske]

what runtime did you use? Lua, 5.1/5.2 LuaJit ?

[lipp]

I have Lua 5.1 and luajit installed. The busted call does not specify the interpreter. Also calling busted --lua=lua and busted --lua=luajit gave a segfault.

I looked at the code and didn't find where the cli arg --lua is being processed... does this work right now?

[Tieske]

--lua is handled in the bootstrap code (the shell scripts) located in./bin

[lipp]

On OSX the situation is a bit different. The test "blocks/hangs" forever (instead of segfaulting).
The scenario can be boiled down to running: busted spec/ev_common_spec.lua (from lua-websockets project dir).
I guess the segfault is some kind of error alias for a work-off problem with the async loop.

[Tieske]

Segfaulting Lua is hard, Luajit is somewhat easier, so I would suspect it to be related to Luajit. Have you tried the latest (just released) version?

[lipp]

Just tried this (on OSX):

busted -l lua spec/ev_common_spec.lua

●○/usr/local/bin/busted: line 41: 95435 Segmentation fault: 11  $COMMAND $BOOTSTRAP_PATH $*

busted spec/ev_common_spec.lua

●○^C^C

So Lua 5.1.5 crashes, whereas Luajit hangs.

[Tieske]

beats me...

first thing that comes to ming would be stacksize, due to recursion. But this seems to happen in the first test, so unlikely?

I had a quick look, and websockets is pure Lua isn't it? maybe best to try and reduce further and post to the Lua list.

[lipp]

yes, lua-websockets is pure Lua. It is the second test which hangs / crashes I think. The strange thing is, that the official 1.9.0 release does not show this behaviour... I'lll investigate deeper.

[lipp]

got it. it's in init.lua pcall is replaced by copcall!
That's why the different loops provided their own pcall.

#173

[Tieske]

imo this is a workaround. It should not happen in the first place.
What loop do you use for websockets?

coxpcall is (supposed to be) transparent, and segfault is a failure anyway, Lua is supposed to be a safe language. Would it be possible to reduce the problem further? this really smells like a Lua bug.

[lipp]

websockets has implementations for ev and copas. but the test affected is ev based.

[Tieske]

Then ev is the other suspect. ..

[DorianGray]

I saw this happen in the first pass at busted code in the file loader. It had trouble with too many nested directories because each nest ended up adding a few layers to the stack. Stack sizes are different in lua on each OS. I think I worked around it by moving the directory traversal code into a coroutine.

[lipp]

I asked on Lua mailing list for any ideas: http://permalink.gmane.org/gmane.comp.lang.lua.general/100273

[Tieske]

recursion should provide a stack overflow error, never a segfault. Ran a simple test

C:\Users\Thijs>type test.lua

print(_VERSION)

function f() f() end
f()



C:\Users\Thijs>test.lua
Lua 5.1
C:\Users\Public\Lua\5.1lfw\lua.exe: C:\Users\Thijs\test.lua:4: stack overflow
stack traceback:
        C:\Users\Thijs\test.lua:4: in function 'f'
        C:\Users\Thijs\test.lua:4: in function 'f'
        C:\Users\Thijs\test.lua:4: in function 'f'
        C:\Users\Thijs\test.lua:4: in function 'f'
        C:\Users\Thijs\test.lua:4: in function 'f'
        C:\Users\Thijs\test.lua:4: in function 'f'
        C:\Users\Thijs\test.lua:4: in function 'f'
        C:\Users\Thijs\test.lua:4: in function 'f'
        C:\Users\Thijs\test.lua:4: in function 'f'
        C:\Users\Thijs\test.lua:4: in function 'f'
        ...
        C:\Users\Thijs\test.lua:4: in function 'f'
        C:\Users\Thijs\test.lua:4: in function 'f'
        C:\Users\Thijs\test.lua:4: in function 'f'
        C:\Users\Thijs\test.lua:4: in function 'f'
        C:\Users\Thijs\test.lua:4: in function 'f'
        C:\Users\Thijs\test.lua:4: in function 'f'
        C:\Users\Thijs\test.lua:4: in function 'f'
        C:\Users\Thijs\test.lua:4: in function 'f'
        C:\Users\Thijs\test.lua:5: in main chunk
        [C]: ?

C:\Users\Thijs>

[Tieske]

@lipp any chance of running this in a debugger and trace where it goes wrong? Probably start with a debug version of ev

[lipp]

This reason for the segfault should be clarified still.

[Tieske]

Fabio suggested using valgrind while running the faulty test. Youmay want to give that a try.

[lipp]

This is deep :(
There is too much valgrind output to share it yet... Valgrind is definitely complaining.
I/it will need some time to figure that out (other high prio stuff on the desk).