[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: base_open fails to set _G
- From: Alexander Gladysh <agladysh@...>
- Date: Fri, 17 Feb 2012 08:36:15 +0400
On Fri, Feb 17, 2012 at 07:50, Alexander Gladysh <agladysh@gmail.com> wrote:
> On Fri, Feb 17, 2012 at 07:15, Alexander Gladysh <agladysh@gmail.com> wrote:
>> Hi, list!
>>
>> (This question contains some hardcore Adobe-specific details. If that
>> distracts you, please view it from the "unknown alpha-quality platform
>> with C compiler" point of view.)
>>
>> I'm debugging a weird bug in the Lua Alchemy that appears with a
>> certain build configuration (with the same Alchemy SWC the bug appears
>> if AIR app built with FDT, and does not appear if built with raw AIR
>> SDK from command-line). In this case the Lua 5.1.4 code is built with
>> llvm-based Adobe Alchemy, to Flash bytecode, and that bytecode is then
>> translated to ARM code for iOS devices via latest AIR, all done by
>> Adobe pipeline, some of which is no longer supported alpha, so things
>> do get pretty weird.
>>
>> I found that base_open() fails to set _G (i.e. lua_getglobal(L, "_G")
>> returns nil). See the code and the output below.
>>
>> I'm a bit baffled. Maybe someone would have some idea on what else to
>> check from the C code side? Meanwhile I will continue to attack the
>> problem from "what is different between the FDT and SDK builds" side.
>>
>> I assume that, at least, Alchemy compiler did not went nuts, since the
>> same SWC works in other configuration, but something in pipeline later
>> (like bytecode to ARM translator) maybe could... Or maybe I just doing
>> something somewhere that leads to undefined behaviour in C.
>>
>> Thank you,
>> Alexander.
>>
>> //
>> // This is what I changed in 5.1.4 code to debug what's happening:
>> //
>> static void base_open (lua_State *L) {
>> /* set global _G */
>>
>> char buf[4096];
>>
>> sztrace("0057.1.0010 -- base_open BEGIN");
>>
>> lua_pushvalue(L, LUA_GLOBALSINDEX);
>>
>> sztrace("0057.1.0020");
>>
>> sprintf(buf, "0057.1.0021 L %p top type %s", L, luaL_typename(L, -1));
>> sztrace(buf);
>>
>> sztrace("0057.1.0022");
>>
>> lua_setglobal(L, "_G");
>>
>> sztrace("0057.1.0023");
>>
>> lua_getglobal(L, "_G");
>>
>> sztrace("0057.1.0024");
>>
>> sprintf(buf, "0057.1.0025 L %p top type %s", L, luaL_typename(L, -1));
>> sztrace(buf);
>>
>> sztrace("0057.1.0026");
>>
>> lua_pop(L, 1);
>>
>> sztrace("0057.1.0030");
>>
>> /* open lib into global table */
>> luaL_register(L, "_G", base_funcs);
>> .... And at this point I see a segfault
>
> A small update: actual crash happens (inside luaL_register() call) in
> luaL_findtable() at this line
>
> https://github.com/lua-alchemy/lua-alchemy/blob/master/alchemy/lib/lua51/src/lauxlib.c#L371
Just in case someone wants to look at the full trace, here it is:
https://gist.github.com/1850707
Code annotations that produced it:
https://github.com/lua-alchemy/lua-alchemy/commit/0927f0aa530275f17089a88d8343bac496229517
Thanks,
Alexander.