Bug#840536: Segfault caused by conflict between lua-socket and libtwolame

[Stephen E. Baker]

Sorry, this is a duplicate of #822825
--
*Stephen E. Baker*
Lead Developer
ERMS Corporation

+1 905-829-8216 x248
stephen.ba...@ermscorp.com 

ERMS: Enterprise-Class Emergency Mass Notification System 

Bug#840536: Segfault caused by conflict between lua-socket and libtwolame

[Stephen E. Baker]

Package: lua-socket
Version: 3.0~rc1+git+321c0c9-1

I am the upstream maintainer of CorsixTH. One of our users reported a 
segfault, which with the help of the luasocket developers we traced back 
to a Debian patch.


The bug report for luasocket: 
https://github.com/diegonehab/luasocket/issues/179


Stacktrace:
#0  0x7fffd40e01e1 in timeout_markstart () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/socket/core.so
#1  0x7fffd40e0599 in buffer_meth_send () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/socket/core.so
#2  0x77688c4d in luaD_precall (L=L@entry=0x745b380, 
func=, func@entry=0x7392af0, nresults=nresults@entry=-1) 
at ldo.c:319

#3  0x7769483d in luaV_execute (L=L@entry=0x745b380) at lvm.c:709
#4  0x77688fc0 in luaD_call (L=L@entry=0x745b380, 
func=, nResults=nResults@entry=-1, 
allowyield=allowyield@entry=1) at ldo.c:402
#5  0x7768516d in lua_pcallk (L=0x745b380, nargs=out>, nresults=-1, errfunc=, ctx=, 
k=) at lapi.c:962
#6  0x7fffd40e479f in ?? () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/socket/core.so
#7  0x77688c4d in luaD_precall (L=L@entry=0x745b380, 
func=, func@entry=0x73929d0, nresults=nresults@entry=3) 
at ldo.c:319

#8  0x7769483d in luaV_execute (L=L@entry=0x745b380) at lvm.c:709
#9  0x77688e40 in unroll (L=0x745b380, ud=) at 
ldo.c:442
#10 0x776885cf in luaD_rawrunprotected (L=L@entry=0x745b380, 
f=f@entry=0x77688e60 , ud=0x2258060) at ldo.c:131
#11 0x77689027 in lua_resume (L=0x745b380, from=, 
nargs=) at ldo.c:543
#12 0x00451760 in luaT_resume (L=0x745b380, f=0x745b380, n=1) at 
CorsixTH/CorsixTH/Src/th_lua.h:114
#13 0x00451103 in l_mainloop (L=0x700db0) at 
CorsixTH/CorsixTH/Src/sdl_core.cpp:260
#14 0x77688c4d in luaD_precall (L=L@entry=0x700db0, 
func=, func@entry=0x7160f50, nresults=nresults@entry=2) 
at ldo.c:319

#15 0x7769483d in luaV_execute (L=L@entry=0x700db0) at lvm.c:709
#16 0x77688f8e in luaD_call (L=L@entry=0x700db0, func=out>, nResults=nResults@entry=-1, allowyield=allowyield@entry=0) at 
ldo.c:402
#17 0x7768502b in lua_callk (L=0x700db0, nargs=, 
nresults=-1, ctx=, k=) at lapi.c:905
#18 0x00452ac4 in CorsixTH_lua_main (L=0x700db0) at 
CorsixTH/CorsixTH/Src/main.cpp:179


Conclusions (copied from the upstream ticket):

This seems to be caused by a conflict between the |buffer_init| function 
of libtwolame and the one provided by luasocket.


Putting a breakpoint on |buffer_init| I see the following backtrace:

|#0 0x7fffed3e0420 in buffer_init () from 
/usr/lib/x86_64-linux-gnu/libtwolame.so.0 #1 0x7fffd40ccfb5 in ?? () 
from /usr/lib/x86_64-linux-gnu/lua/5.2/socket/core.so #2 
0x77687c75 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0 |


Here you can see luasocket calling into buffer_init from libtwolame. A 
simple hack to |src/buffer.h| makes the problem go away:


|--- luasocket-3.0~rc1+git+321c0c9.orig/src/buffer.h +++ 
luasocket-3.0~rc1+git+321c0c9/src/buffer.h @@ -34,6 +34,8 @@ typedef 
struct t_buffer_ { } t_buffer; typedef t_buffer *p_buffer; +#define 
buffer_init foo_bar_buffer_init + int buffer_open(lua_State *L); void 
buffer_init(p_buffer buf, p_io io, p_timeout tm); int 
buffer_meth_send(lua_State *L, p_buffer buf); |


The root cause looks like a patch that Debian has added. Dropping that 
patch also seems to have fixed the problem.


The patch referenced is: 
https://sources.debian.net/patches/luasocket/3.0%7Erc1%2Bgit%2B321c0c9-1/0001-add-LUASOCKET_API-to-timeout_markstart-init-for-lua-.patch/