https://bugzilla.wikimedia.org/show_bug.cgi?id=68196
--- Comment #12 from Tim Starling <tstarl...@wikimedia.org> ---
Also, because Lua is in the stack, the in_lua flag is set, so "slop" is zero.
That is to say, the hack intended to fix bug 59130 is disabled. The Lua
userspace takes the usage to within 36 bytes of the limit, and
lua_pushcclosure() tries to allocate 40, so after the error is handled, it's
assured that re-entering the same state will cause an unprotected OOM.
in_lua and in_php are both flags indicating the contents of the stack, not the
immediate caller. Maybe we need a third flag which indicates that the immediate
caller is unprotected.
Also, I think the 1 MB slop might be a bit too conservative. Since the result
of an OOM is a crash, we should probably just disable the memory limit entirely
for unprotected calls.
A third thing we should do is to compile our own Lua library in C++. This might
not be convenient for all reusers, but it causes Lua to use exceptions for
error propagation, instead of setjmp/longjmp, which should be safer.
#if defined(__cplusplus)
/* C++ exceptions */
#define LUAI_THROW(L,c) throw(c)
#define LUAI_TRY(L,c,a) try { a } catch(...) \
{ if ((c)->status == 0) (c)->status = -1; }
Note that it does catch and discard all exceptions, even ones from HHVM -- I
noticed this during design work for https://github.com/facebook/hhvm/pull/1986
. The Lua VM is not exception-safe, so it has a choice between discarding
exceptions or crashing. That's one of the reasons why EZC catches and saves
exceptions: to prevent them from breaking Lua. If we were integrating Lua as a
non-EZC HHVM extension, we would still need that catch and save layer,
equivalent to PR 1986.
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
