Hmm, looks like uhttpd.lua needs to be updated with some changes in uhttpd2 - the handler should no longer send the firstline of the response (HTTP/1.0 200 OK).
I guess luci-sgi-uhttpd is not really used very much - I thought it would be very attractive on embedded systems to avoid fork'ing for each HTTP request. Can anyone comment on why the default is luci-sgi-cgi? On Sun, Mar 17, 2013 at 3:33 PM, Catalin Patulea <[email protected]> wrote: > Well, I fixed the segfaults by adding -llua to a bunch of libraries, > but now I get a lua exception in browser: > > Content-Type: text/plain > Cache-Control: no-cache > Expires: 0 > > /usr/lib/lua/luci/sgi/uhttpd.lua:48: attempt to compare number with string > stack traceback: > /usr/lib/lua/luci/sgi/uhttpd.lua:48: in function 'src' > /usr/lib/lua/luci/ltn12.lua:368: in function 'step' > /usr/lib/lua/luci/http/protocol.lua:657: in function 'parse_message_body' > /usr/lib/lua/luci/http.lua:116: in function '_parse_input' > /usr/lib/lua/luci/http.lua:60: in function </usr/lib/lua/luci/http.lua:58> > (tail call): ? > /usr/lib/lua/luci/dispatcher.lua:148: in function 'authen' > /usr/lib/lua/luci/dispatcher.lua:370: in function 'dispatch' > /usr/lib/lua/luci/dispatcher.lua:195: in function > </usr/lib/lua/luci/dispatcher.lua:194> > > On Sun, Mar 17, 2013 at 2:14 PM, Catalin Patulea <[email protected]> wrote: >> I think this might be a missing dependency from nixio.so on liblua.so. >> >> uhttpd_lua.so does depend on it: >> $ mips-openwrt-linux-objdump -x uhttpd_lua.so | grep NEEDED >> NEEDED libcrypt.so.0 >> NEEDED liblua.so.5.1.5 >> NEEDED libm.so.0 >> NEEDED libdl.so.0 >> NEEDED libgcc_s.so.1 >> NEEDED libc.so.0 >> >> But nixio.so doesn't, so I think luaX symbols don't get resolved by dl: >> $ mips-openwrt-linux-objdump -x nixio.so | grep NEEDED >> NEEDED libcrypt.so.0 >> NEEDED libgcc_s.so.1 >> NEEDED libc.so.0 >> >> On Sun, Mar 17, 2013 at 1:34 PM, Catalin Patulea <[email protected]> wrote: >>> Got nixio.so rebuilt with symbols, segfault is in >>> luci/libs/nixio/src/nixio.c: >>> >>> /* entry point */ >>> NIXIO_API int luaopen_nixio(lua_State *L) { >>> /* create metatable */ >>> luaL_newmetatable(L, NIXIO_META); // XXX segfault here >>> >>> >>> On Sun, Mar 17, 2013 at 1:12 PM, Catalin Patulea <[email protected]> >>> wrote: >>>> I'm running r35995 and seeing uhttpd segfault at startup when the Lua >>>> handler is enabled: >>>> >>>> # /usr/sbin/uhttpd -f -h /www -r gate -l / >>>> luci -L /usr/lib/lua/luci/sgi/uhttpd.lua -t 60 -T 30 -A 1 -n 3 -p >>>> 0.0.0.0:80 >>>> Segmentation fault >>>> >>>> I ran it under gdbserver, here's a backtrace: >>>> (gdb) bt >>>> #0 0x00000000 in ?? () >>>> #1 0x77e6c18c in luaopen_nixio () from >>>> staging_dir/target-mips_r2_uClibc-0.9.33.2/root-ar71xx/usr/lib/lua/nixio.so >>>> #2 0x77ebb888 in luaD_precall () from >>>> staging_dir/target-mips_r2_uClibc-0.9.33.2/root-ar71xx/usr/lib/liblua.so.5.1.5 >>>> #3 0x77ebba40 in luaD_call () from >>>> staging_dir/target-mips_r2_uClibc-0.9.33.2/root-ar71xx/usr/lib/liblua.so.5.1.5 >>>> #4 0x77eb65e8 in lua_call () from >>>> staging_dir/target-mips_r2_uClibc-0.9.33.2/root-ar71xx/usr/lib/liblua.so.5.1.5 >>>> #5 0x77ed6d44 in ll_require () from >>>> staging_dir/target-mips_r2_uClibc-0.9.33.2/root-ar71xx/usr/lib/liblua.so.5.1.5 >>>> #6 0x77ebb888 in luaD_precall () from >>>> staging_dir/target-mips_r2_uClibc-0.9.33.2/root-ar71xx/usr/lib/liblua.so.5.1.5 >>>> #7 0x77ec8e84 in luaV_execute () from >>>> staging_dir/target-mips_r2_uClibc-0.9.33.2/root-ar71xx/usr/lib/liblua.so.5.1.5 >>>> #8 0x77ebba58 in luaD_call () from >>>> staging_dir/target-mips_r2_uClibc-0.9.33.2/root-ar71xx/usr/lib/liblua.so.5.1.5 >>>> #9 0x77eb65e8 in lua_call () from >>>> staging_dir/target-mips_r2_uClibc-0.9.33.2/root-ar71xx/usr/lib/liblua.so.5.1.5 >>>> #10 0x77ed6d44 in ll_require () from >>>> staging_dir/target-mips_r2_uClibc-0.9.33.2/root-ar71xx/usr/lib/liblua.so.5.1.5 >>>> #11 0x77ebb888 in luaD_precall () from >>>> staging_dir/target-mips_r2_uClibc-0.9.33.2/root-ar71xx/usr/lib/liblua.so.5.1.5 >>>> #12 0x77ec8e84 in luaV_execute () from >>>> staging_dir/target-mips_r2_uClibc-0.9.33.2/root-ar71xx/usr/lib/liblua.so.5.1.5 >>>> #13 0x77ebba58 in luaD_call () from >>>> staging_dir/target-mips_r2_uClibc-0.9.33.2/root-ar71xx/usr/lib/liblua.so.5.1.5 >>>> #14 0x77ebaae0 in luaD_rawrunprotected () from >>>> staging_dir/target-mips_r2_uClibc-0.9.33.2/root-ar71xx/usr/lib/liblua.so.5.1.5 >>>> #15 0x77ebbca4 in luaD_pcall () from >>>> staging_dir/target-mips_r2_uClibc-0.9.33.2/root-ar71xx/usr/lib/liblua.so.5.1.5 >>>> #16 0x77eb66b8 in lua_pcall () from >>>> staging_dir/target-mips_r2_uClibc-0.9.33.2/root-ar71xx/usr/lib/liblua.so.5.1.5 >>>> #17 0x77eed178 in uh_lua_state_init () at >>>> /mnt/shared/openwrt/build_dir/target-mips_r2_uClibc-0.9.33.2/uhttpd-2013-01-22/lua.c:168 >>>> #18 lua_plugin_init (o=<optimized out>, c=<optimized out>) >>>> at >>>> /mnt/shared/openwrt/build_dir/target-mips_r2_uClibc-0.9.33.2/uhttpd-2013-01-22/lua.c:292 >>>> #19 0x00402150 in main (argc=20, argv=0x0) at >>>> /mnt/shared/openwrt/build_dir/target-mips_r2_uClibc-0.9.33.2/uhttpd-2013-01-22/main.c:375 >>>> >>>> I looked around, there's something about module imports being done >>>> differently in Lua 5.1, but I'm not sure how exactly it applies to >>>> uhttpd: >>>> http://forum.luahub.com/index.php?topic=2569.0 >>>> >>>> Any ideas or additional information I can provide? _______________________________________________ openwrt-users mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-users
