5.1 Crashing in luaopen_io

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

5.1 Crashing in luaopen_io

Stockdale, Daire, SOE

Hello

 

I am having crashes when attempting to use Lua 5.1 (source code from http://www.lua.org/work/lua-5.1-rc.tar.gz taken 3 Feb 2006). A field in L->ci->func->value appears to be uninitialised.

 

Is this a known bug or am I doing something stupid? The Lua compiler and console (luac.c and lua.c) code seems to work however it arrives at the index2adr call via a different code path during which the field appears to get correctly initialised. 

 

Thanks for the help,

 

D. Stockdale

 

 

 

Complete application code:

 

    #include <stdio.h>

    #include <lua.h>

    #include <lauxlib.h>

    #include <lualib.h>

   

    int main (int argc, char* argv[]) {

 

      lua_State *L = lua_open(); 

      luaopen_base(L);           

      luaopen_table(L);          

      luaopen_io(L);                // <-- Crashes in here             

      luaopen_string(L);         

      luaopen_math(L);           

   

      lua_close(L);

      return 0;

    }

           

Callstack:

 

Lua Sample.exe!index2adr(lua_State * L=0x00323d80, int idx=-10001)  Line 64 + 0xf         

Lua Sample.exe!lua_replace(lua_State * L=0x00323d80, int idx=-10001)  Line 203 + 0xd    

Lua Sample.exe!luaopen_io(lua_State * L=0x00323d80)  Line 513 + 0xe    

Lua Sample.exe!main()  Line 175 + 0x9  

Lua Sample.exe!mainCRTStartup()  Line 259 + 0x19        

 

 

Crash location:

 

static TValue *index2adr (lua_State *L, int idx) {

  if (idx > 0) {

    TValue *o = L->base + (idx - 1);

    api_check(L, idx <= L->ci->top - L->base);

    if (o >= L->top) return cast(TValue *, luaO_nilobject);

    else return o;

  }

  else if (idx > LUA_REGISTRYINDEX) {

    api_check(L, idx != 0 && -idx <= L->top - L->base);

    return L->top + idx;

  }

  else switch (idx) {  /* pseudo-indices */

    case LUA_REGISTRYINDEX: return registry(L);

    case LUA_ENVIRONINDEX: {

      Closure *func = curr_func(L);   // *** THIS RETURNS AN INVALID POINTER ***

      sethvalue(L, &L->env, func->c.env); //&(o)->value.gc->cl)

      return &L->env;

    }

    case LUA_GLOBALSINDEX: return gt(L);

    default: {

      Closure *func = curr_func(L);

      idx = LUA_GLOBALSINDEX - idx;

      return (idx <= func->c.nupvalues)

                ? &func->c.upvalue[idx-1]

                : cast(TValue *, luaO_nilobject);

    }

  }

}




========================================
DISCLAIMER

The contents of this e-mail and any attachments are confidential to the intended recipient and may also be legally privileged. Unless you are the named addressee (or authorised to receive for the addressee) of this email you may not copy, disclose or distribute it to anyone else.

If you have received this email in error, please notify us immediately by e-mail on [hidden email] and then delete the email and any copies. The SEGA Group have made all reasonable efforts to ensure that this e-mail and any attached documents or software are free from software viruses, but it is the recipient's responsibility to confirm this.

========================================
Reply | Threaded
Open this post in threaded view
|

Re: 5.1 Crashing in luaopen_io

Antero Vipunen
Hi,

Stockdale, Daire, SOE wrote:

> Is this a known bug or am I doing something stupid? The Lua compiler
> and console (luac.c and lua.c) code seems to work however it arrives
> at the index2adr call via a different code path during which the field
> appears to get correctly initialised.
>
Quote from Lua 5.1 reference manual:
 >These functions are declared in |lualib.h| and should not be called
directly: you must call them like >any other Lua C function, e.g., by
using |lua_call|.

AMDG,
  Antero Vipunen.
Reply | Threaded
Open this post in threaded view
|

Re: Re: 5.1 Crashing in luaopen_io

Stockdale, Daire, SOE
In reply to this post by Stockdale, Daire, SOE

luaopen_string
luaopen_table
luaopen_math
luaopen_debug
luaopen_io
luaopen_package
luaopen_base

Quote from Lua 5.1 reference manual:
 >These functions are declared in |lualib.h| and should not be called
directly: you must call them like any other Lua C function, e.g., by
using |lua_call|.

Are these the only C api functions subject to this special case, or must
all of the C api be accessed via the lua_call routine? The above
sentence seems to imply the latter.

If these are the only special case calls, then maybe it would be more
useful to either make these work as previously, or deprecate the 5.0
signature and hint that these functions have changed significantly.

Thanks for the help!

D. Stockdale


 
========================================
DISCLAIMER

The contents of this e-mail and any attachments are confidential to the intended recipient and may also be legally privileged.  Unless you are the named addressee (or authorised to receive for the addressee) of this email you may not copy, disclose or distribute it to anyone else.  

If you have received this email in error, please notify us immediately by e-mail on [hidden email] and then delete the email and any copies.  The SEGA Group have made all reasonable efforts to ensure that this e-mail and any attached documents or software are free from software viruses, but it is the recipient's responsibility to confirm this.

========================================

Reply | Threaded
Open this post in threaded view
|

Re: 5.1 Crashing in luaopen_io

Eero Pajarre-3
Stockdale, Daire, SOE wrote:

> luaopen_string
> luaopen_table
> luaopen_math
> luaopen_debug
> luaopen_io
> luaopen_package
> luaopen_base
>
> Quote from Lua 5.1 reference manual:
>  >These functions are declared in |lualib.h| and should not be called
> directly: you must call them like any other Lua C function, e.g., by
> using |lua_call|.
>
> Are these the only C api functions subject to this special case, or must
> all of the C api be accessed via the lua_call routine? The above
> sentence seems to imply the latter.
>


AFAIK it is only these functions which need the special handling.
(and actually I think only couple of them really require it)

And yes, I also did not appreciate this change. I would have
prefered something more visible, like function name change.
Also when I was debugging this in my program, the error was not
"access through zero pointer" but "access through un-initialized
pointer" which I thought is worse debugging wise.

It is of course easy to avoid this problem by using (or copying)
the code from linit.c

        Eero