https://bugzilla.wikimedia.org/show_bug.cgi?id=68196
--- Comment #9 from Brett Simmers <[email protected]> --- After some fun times with gdb, I'm almost certain this is luasandbox related, though I'm not yet sure what the root cause is. I was seeing what looked like some C++ frames disappearing without the relevant destructors being called, so I suspected something was going wrong with a longjmp somewhere and went with that. http://pastebin.com/mKeqJYLZ is a stacktrace I took right before everything went off the rails. Notice that ExecutionContext::invokeFunc and luasandbox_call_helper both appear twice, indicating that PHP called into lua, which called back into PHP, which is now calling into lua again (this is expected behavior, right?). I previously stepped through one longjmp that didn't escape the call to luasandbox_call_helper in frame #5, but the one about to happen doesn't go so well. I stepped through this longjmp up until it restored the previous stack and took another backtrace: http://pastebin.com/6UgHygPs. Notice that it appears to have jumped from the nested invocation of lua to the outer one, skipping over all the hhvm frames in between the two. This explains how we eventually end up in the outmost invokeFunc frame with the VM state still looking like the nested frame: the nested VM state is supposed to be popped by a destructor in invokeFunc that never ran. I'm done for today but the best theory I have so far is that there's some global setjmp/longjmp buffer in liblua that's being used improperly. Is liblua supposed to handle reentrancy like this? I noticed that lua_pushcclosure() is in the backtrace for the problematic longjmp but not for the previous one; maybe that's related? -- 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 [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
