> 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.In a normal situation (inside a protected call), this is a typical call
> 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.
> 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:
n = (*f)(L); /* do the actual call */
When there is an error, the long jump skips this lua_lock, which
compensates the skipped lua_unlock in function lua_error. Everything