Crash in Lua 5.0

[Reuben Thomas <rrt@...>]

I'm having a problem with Lua 5.0 on RedHat 9. In particular, starting up
lua and running the line

io.input("/home/rrt/ToDo"); for line in io.lines() do print(line) end

causes a segfault.

This only happens if I build Lua dynamically. Statically it works fine. I
have had similar problems with different Lua code in Lua 4.0 since moving
to RedHat 9, so I wonder if there's a problem with GCC or glibc there. I
didn't worry about the Lua 4 problems, because I don't need Lua built
dynamically, so I just rebuilt it statically.

I have tried running the above code with Valgrind
(http://developer.kde.org/~sewardj), but it didn't show any errors, so it
doesn't seem to be an obvious malloc-related bug in Lua. The stack trace I
get in GCC is:

Program received signal SIGSEGV, Segmentation fault.
0x420744f5 in _int_malloc () from /lib/tls/libc.so.6
(gdb) where
#0  0x420744f5 in _int_malloc () from /lib/tls/libc.so.6
#1  0x4207360b in malloc () from /lib/tls/libc.so.6
#2  0x42073832 in realloc () from /lib/tls/libc.so.6
#3  0x40024752 in luaM_realloc (L=0x804a408, block=0x0, oldsize=0,
size=85) at lmem.c:77
#4  0x4002859e in newlstr (L=0x804a408, str=0xbfffc2ac "have \"any header
contains\" part of recipient address? (These are all\n", l=68,
    h=1562000025) at lstring.c:52
#5  0x4002873a in luaS_newlstr (L=0x804a408, str=0xbfffc2ac "have \"any
header contains\" part of recipient address? (These are all\n",
    l=68) at lstring.c:86
#6  0x4001bf91 in lua_pushlstring (L=0x804a408, s=0xbfffc2ac "have \"any
header contains\" part of recipient address? (These are all\n",
    len=68) at lapi.c:408
#7  0x40035df2 in emptybuffer (B=0xbfffc2a0) at lauxlib.c:341
#8  0x40035f69 in luaL_pushresult (B=0xbfffc2a0) at lauxlib.c:387
#9  0x4003976e in read_line (L=0x804a408, f=0x804eb88) at liolib.c:337
#10 0x40039b0a in io_readline (L=0x804a408) at liolib.c:422
#11 0x400204f4 in luaD_precall (L=0x804a408, func=0x804a564) at ldo.c:260
#12 0x400206a2 in luaD_call (L=0x804a408, func=0x804a564, nResults=1) at
ldo.c:311
#13 0x4002cf05 in luaV_execute (L=0x804a408) at lvm.c:712
#14 0x400206b9 in luaD_call (L=0x804a408, func=0x804a534, nResults=-1) at
ldo.c:313
#15 0x4001c6cc in f_call (L=0x804a408, ud=0xbfffe5a0) at lapi.c:672
#16 0x4001fbe6 in luaD_rawrunprotected (L=0x804a408, f=0x4001c6aa
<f_call>, ud=0xbfffe5a0) at ldo.c:88
#17 0x40020a76 in luaD_pcall (L=0x804a408, func=0x4001c6aa <f_call>,
u=0xbfffe5a0, old_top=36, ef=24) at ldo.c:403
#18 0x4001c750 in lua_pcall (L=0x804a408, nargs=0, nresults=-1, errfunc=1)
at lapi.c:685
#19 0x08048ff1 in lcall (narg=0, clear=0) at lua.c:138
#20 0x0804956c in manual_input () at lua.c:283
#21 0x080496a7 in handle_argv (argv=0xbfffe8b4, interactive=0xbfffe63c) at
lua.c:303
#22 0x08049ab2 in pmain (l=0x804a408) at lua.c:415
#23 0x400204f4 in luaD_precall (L=0x804a408, func=0x804a51c) at ldo.c:260
#24 0x400206a2 in luaD_call (L=0x804a408, func=0x804a51c, nResults=0) at
ldo.c:311
#25 0x4001c829 in f_Ccall (L=0x804a408, ud=0xbfffe810) at lapi.c:709
#26 0x4001fbe6 in luaD_rawrunprotected (L=0x804a408, f=0x4001c75b
<f_Ccall>, ud=0xbfffe810) at ldo.c:88
#27 0x40020a76 in luaD_pcall (L=0x804a408, func=0x4001c75b <f_Ccall>,
u=0xbfffe810, old_top=12, ef=0) at ldo.c:403
#28 0x4001c865 in lua_cpcall (L=0x804a408, func=0x8049a37 <pmain>,
ud=0xbfffe840) at lapi.c:719
#29 0x08049b35 in main (argc=1, argv=0xbfffe8b4) at lua.c:433
#30 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6

so it seems that something is corrupting the malloc heap. Since valgrind
isn't detecting it, maybe it's a bug in glibc...(a code generation bug in
GCC that causes Lua to do something bad should be caught by Valgrind).

Anyway, I'll continue to poke at this a bit and see if I come up with
anything, but I'm posting to the list in case anyone else has had a
similar experience.

I'm afraid this means that my RedHat 9 binary RPM is unreliable.
Rebuilding the source RPM may give you better mileage (especially on non
RH9 systems!). Of course, if it's a glibc bug, then the RPM should be fine
on other systems too.

-- 
http://www.mupsych.org/~rrt/
poetry, n.  the art of squeezing blood into stones