For openwrt-devel: this is related to a segfault, then a lua
assertion, in luci-sgi-uhttpd when it is enabled.

Here are some patches that helped with this.

- Respect EXTRA_CFLAGS and EXTRA_LDFLAGS in lua and luci packages.
This came in handy to quickly rebuild with debug symbols without
changing config etc. (make package/lua/compile EXTRA_CFLAGS='-ggdb').
I didn't need EXTRA_LDFLAGS but I added for completeness.
0001-lua-respect-EXTRA_CFLAGS-and-EXTRA_LDFLAGS.patch - patch against
openwrt trunk
luci-respect-extra-flags.patch - patch against
svn.luci.subsignal.org/luci/trunk/contrib/package/luci

- Pass -llua when building libuci, nixio and the luci template parser
module. This is the actual segfault fix. It was doing a call to NULL,
probably because dl wasn't resolving liblua symbols like
luaL_newmetatable.
0002-uci-add-patch-to-pass-llua-when-building-libuci.so.patch
luci-pass-llua.patch

The above add patches to each openwrt package, but I could reformat
them to patch the upstream repos if the maintainers are interested
(jow, nbd?).

And finally, fix uhttpd.lua to not send firstline:
luci-uhttpd-nofirstline.patch

Again, this is a patch against the package, but I can resend as an
upstream patch.

With these, 'uhttpd -L /usr/lib/lua/luci/sgi/uhttpd.lua' works and
serves luci in-process.

On Sun, Mar 17, 2013 at 3:59 PM, Catalin Patulea <c...@vv.carleton.ca> wrote:
> 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 <c...@vv.carleton.ca> 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 <c...@vv.carleton.ca> 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 <c...@vv.carleton.ca> 
>>> 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 <c...@vv.carleton.ca> 
>>>> 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?

Attachment: 0001-lua-respect-EXTRA_CFLAGS-and-EXTRA_LDFLAGS.patch
Description: Binary data

Attachment: 0002-uci-add-patch-to-pass-llua-when-building-libuci.so.patch
Description: Binary data

Attachment: luci-pass-llua.patch
Description: Binary data

Attachment: luci-respect-extra-flags.patch
Description: Binary data

Attachment: luci-uhttpd-nofirstline.patch
Description: Binary data

_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reply via email to