One more patch that I forgot - env.CONTENT_LENGTH is a string, so it needs a 'tonumber'.
On Sun, Mar 17, 2013 at 4:28 PM, Catalin Patulea <c...@vv.carleton.ca> wrote:
> 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?
luci-uhttpd-clen-tonumber.patch
Description: Binary data
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
