lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


> I find there is an invocation to lua_unlock() after luaG_errormsg(), which
> will never return because it calls longjmp(). So the lua_unlock() is
> deadcode, and it seems an unbalanced lock/unlock bug.
> 
> [...]
> satisfactory to me.
> 
> One says, when a long-jump happens because of the luaG_errormsg(), the
> control is still within Lua and there must be another lua_unlock() waiting
> for. But, I think that lua_unlock() is paired with another lua_lock(), so
> the lua_lock() immediately before the long-jump is still unpaired.
> 
> Another says it found the missing lua_unlock() in luaD_throw(). But I think
> the only lua_unlock() within luaD_throw() is in a branch which is hit only
> when there is no protected call at all.

In a normal situation (inside a protected call), this is a typical call
sequence:

> lua_pcall       - lock
  > luaD_precall  - unlock to call a C function
    >lua_error    - lock and does a long jump
< lua_pcall       - unlock

More specifically, where a C function is called by luaD_precall, the
code looks like this:

      lua_unlock(L);
      n = (*f)(L);  /* do the actual call */
      lua_lock(L);

When there is an error, the long jump skips this lua_lock, which
compensates the skipped lua_unlock in function lua_error. Everything
is correct.

-- Roberto