The @ sign requires @codingStandardsIgnoreLine Generic.PHP.NoSilencedErrors.Discouraged
\MediaWiki\suppressWarnings() doesn't need a @codingStandardsIgnoreLine.
Bug: T191247
Change-Id: I8ce2a49c9327a452cf5fa64f96c7cde55702bf28
When passing an array from PHP to Lua, stringify integer array keys
beyond the range a lua_Number can represent.
When passing a table from Lua to PHP,
* Avoid exponential encoding for integer keys beyond 1e14, so Zend PHP
will interpret them as integers.
* Always encode integer keys as integers, so HHVM will interpret them as
integers.
* Detect collisions, e.g. { [0] = 'foo', ["0"] = 'bar' }
Bug: T186240
Change-Id: I078068ed57df078248a307608381614bdfc70801
For integers from Lua to PHP, make sure they won't use exponential
notation that will confuse unserialize(), and pass the integer size from
PHP so Lua can know which numbers are representable as integers.
For doubles in both directions, increase the precision to avoid
truncation of the least significant bits.
Change-Id: Icfaff71cab0ee1aac04acf752d108049b5569380
When we're making a call from Lua to PHP, serialization errors should be
propagated to whatever in Lua made the call. That works fine.
But when we're returning data in response to a call from PHP, if there's
a serialization error we need to catch it and tell PHP about it.
Otherwise PHP just gets a useless "the interpreter exited".
Change-Id: Iaac498fa2e486631d38e2366977b360140756519
PHP 7.2 made the questionable decision to raise a warning for
count( null ). So test for null explicitly before calling count in the
one place where null is expected.
Bug: T181891
Change-Id: I94146c14b63e32ad1e9f2ab9de9ebc403b251102
I252ec046 noticeably broke things by adding a dependency on the pcntl
functions, which tend not to be present under Apache.
It also subtly broke exit handling by using proc_close()'s return value,
which PHP mangles in such a way that we can't tell the difference
between an actual XCPU kill and exit( SIGXCPU ). This one wasn't noticed
because the pcntl functions interpret everything proc_close() is going
to return as a signal kill and we didn't test the 'exited' code path.
I'm not sure what was going on in I57cdf8aa since it provides no details
about what it was trying to fix, but that would have broken signal
handling in the other way: Ibf5f4656 worked because proc_open() on Linux
executes the command by passing it to /bin/sh -c, and that shell is
going to turn any signal that kills Lua (e.g. the SIGXCPU) into an exit
status of 128+signum.
To avoid proc_close()'s broken return value while also avoiding the
race, we can loop on proc_get_status() until $status['running'] is
false.
To have signals that kill Lua actually be interpreted as signals, we
have two options: add an "exec" in front of the command so proc_open()'s
/bin/sh -c is execed away, or detect shell-style signal reporting and
convert it. We may as well do both.
Bug: T128048
Change-Id: I8a62e1660fe1694e9ba5de77d01960c1ab4580aa
https://www.mediawiki.org/wiki/Extension:Scribunto says that master
requires 1.25+, so let's remove checks for stuff that was added before
that.
* PPFrame::getTTL() was in 1.24.
* PPFrame::setTTL() was in 1.24.
* PPFrame::isVolatile() was in 1.24.
* Parser::fetchCurrentRevisionOfTitle() was in 1.24.
* ObjectCache::getLocalServerInstance() was added in 1.27, so restore the call to ObjectCache::newAccelerator() as BC.
This also removes BC with the php-luasandbox extension older than 1.6, which
was released before MediaWiki 1.22.
Bug: T148012
Change-Id: I36e37f3b65d0f167e1d28b00e0842d9721feee31
The following continue to be ignored:
* Generic.Arrays.DisallowLongArraySyntax.Found, because I'm not sure
Scribunto is ready to abandon old version support in master.
* MediaWiki.ControlStructures.AssignmentInControlStructures.AssignmentInControlStructures,
because it's overly strict for its purpose.
Squiz.Classes.ValidClassName.NotCamelCaps isn't ignored globally, we
just ignore it explicitly every place it's needed.
Change-Id: I307668da6ef7b3e23da19b1fd1e08914239b99b3
These binaries were compiled from a manually lua-5.1.5 source tree.
Linux binaries were built by Anomie. Mac OS X and Windows by dpatrick.
Bug: T72541
Change-Id: I6af0f042c491785cce26afc186a148c83c4f3414
Marius found a race condition in the handling of SIGXCPU: the pipes
would close, causing the read/write to complete, before the status of
the process changed, so the status would randomly be "running" for a few
milliseconds after proc_get_status() was called.
So: terminate the process unconditionally after an I/O error. Get the
exit status from proc_close(), since that's the only way to get the
status of a terminated process while simultaneously waiting for it to
exit. Also fix signal identification as in unmerged patch I57cdf8aa.
Change-Id: I252ec046e82063a868c1094e81705cb5e847db92
This is apparently unofficially deprecated, and we can do things a bit
more straightforwardly by using ParserOutput::addJsConfigVars() to
communicate the error messages to the JS.
This also takes the opportunity to move "ext.scribunto", which is mostly
about errors, to "ext.scribunto.errors".
Bug: T75618
Change-Id: I1577dab2dab1bd79cb127879de141fdbb8963aeb
There are like a billion things missing in the inline documentation
of this extension. Wow. This is what I can do for now.
Change-Id: I019c24d13cf5cb22dde4d710b86ef8f976e1ec96
People have been complaining that they can't find the log data anywhere.
The new parser limit report seems a good place to show this information.
Change-Id: If2abf27f7779d92ff7c7a1f32b2a54a5de521678
Clean up trailing whitespace from all of our code, and add comments
indicating that apparently unused variables are ScopedCallbacks.
Change-Id: I8e5997797cc7b1c64c5351ec112a18f30edc8fef
LuaStandalone only uses 2 functions from mw.lua, so move them to their own
file to avoid running the whole thing twice.
Change-Id: Ia4d58f44be17f7a71666dbe750e66d9d90cb5c2f
The LuaStandalone interpreter needs to keep a mapping from integers
returned to PHP to the corresponding function. But if it never releases
these functions when PHP no longer has any reference to them, it can
result in Lua running out of memory if a module with a large number of
functions is invoked many times in one page.
The fix here is to track which function ids are referenced from PHP, and
periodically send the list to Lua so it can remove any that are no
longer used from its cache.
This also takes care of another issue where having multiple interpreter
instances and passing function objects from one into another could call
the wrong function in Lua.
Bug: 51886
Change-Id: I4f15841051f7748d1d6df24080949e5cbd88f217
Change Ie065c7b5 added an option to show profiling data at the bottom of
preview pages, and with it new hooks to gather and format this data in a
more structured way than is possible with ParserLimitReport. This change
adds support for the new hooks.
Depends-On: I7799616a602d90e1b8d3f0ece35811ca387bade7
Change-Id: Idffd2d78f9a0217c99c07cbbfc844d6daf0172f7
PHP can't handle having arrays/objects or functions as keys in its
arrays, so make sure we don't try to pass them from Lua. Booleans aren't
really well-handled either, so let's disallow them too.
Also, add tests for proper stringification of floats and infinities when
those are used as keys.
Note this behavior change is needed to match the change in LuaSandbox
for fixing bug 54527, but isn't itself a security issue.
Change-Id: I1e2951bbe8cb78358650ad377bf7119fcac4485d
The binaries currently provided were compiled against glibc 2.11+, so
people using CentOS 5 (which has glibc 2.5) are not able to use them.
The binaries in this patch were compiled in VMs installed with CentOS
5.9, and so should work for more people; at a glance, it looks like
glibc 2.3 or later will probably work now.
Bug: 51333
Change-Id: Iac1f2373bbc0bbca8783c82c09eff51ffd5e3761
If the user is on a webhost that has proc_open listed in PHP's
disable_functions directive, we should give a better error message.
Until we no longer support PHP below 5.4, we should do the same for
safe_mode. And since we're doing that, we may as well report any other
warnings if proc_open fails, too.
In addition, this cleans up error handling in
Scribunto_LuaEngine::load() so it doesn't pretend the interpreter is
loaded if getInterpreter() throws an exception. Otherwise other code
winds up with PHP fatal errors trying to access a null value.
Bug: 50706
Change-Id: I2887b722e089fd7a526aa7dcab9c80deb343d8ac
If the interpreter exits before the end of the page, then the call to
Scribunto_LuaStandaloneEngine::getLimitReport() throws an uncaught
exception when it tries to access the interpreter. Catch it.
Change-Id: I7ce4f09b1b2206f13ab0f422de35e0b69a3b24d5
On Windows for LuaStandalone, the lua executable's standard output is a
text-mode file handle, even if the pipe is opened from PHP with the
binary flag. Which means that when Lua returns a "\n", it gets silently
rewritten to "\r\n" and the unserialization fails.
So, change the protocol for Lua→PHP messages to encode \r and \n (and \
itself, as the escape character) to avoid this issue.
Bug: 46294
Change-Id: I73b5f44e8aa0334f5fd03013dc027d1a57318349
Use the SoftwareInfo hook to add the versions of LuaSandbox and Lua to
Special:Version.
Bug: 39655
Change-Id: I912197efee0211066677c4d46e638fb546a410c6
Currently, the time taken to parse the arguments passed to a Lua
function from #invoke will be counted against Lua's 10-second limit.
This is counterintuitive, and can remove incentive for users to convert
templates to Lua since they may have to convert a whole stack at once.
Note this requires change I11881232 to mediawiki/php/luasandbox to
actually have any effect.
Bug: 45684
Change-Id: I773950e4c399b8a1cfa6d1cde781a069d286b3bd
Adds a base class for libraries with some utility functions in PHP, and a
Lua library with utility functions for use from Lua.
Change-Id: I3d67b1de8bc50488fe3a722e4e2de5849285d127
In Lua, a table entry with a nil value is the same as a table entry that
doesn't exist. So when serializing for transfer to PHP, these keys will
be skipped. For a table as an associative array this isn't much of a
problem, but for a table as a list it means we have missing indexes.
Some of Lua's functions for handling "lists" (i.e. tables with numeric
keys) also have a problem when the list contains nils.
To work around these issues when passing argument lists and return value
lists, pass the number of elements along with the sparse list. On the
PHP end we can use this to fill in the missing nulls, and on the Lua
end we can pass this count to unpack() to avoid the problems on the Lua
side.
Change-Id: I858e3905a06e377693301da2b8bc534808f00e3e
Built-in modules (e.g. the upcoming ustring) should be able to extend
the string metatable, but user modules (and the debug console) should
not be able to.
But currently built-in modules cannot extend the string metatable in
LuaStandalone, while in LuaSandbox the string metatable can be extended
in the console. Fix this and add unit tests.
Change-Id: I15f5598fed318f2fe26b08ec47e16053dddc13c4
Currently, the only way for PHP to pass a function to Lua is to pass
back a function that it received from Lua. This means, for example, that
PHP cannot implement a Lua iterator function except by registering a
library holding the function or by using loadString.
This changeset adds Scribunto_LuaInterpreter::wrapPhpFunction (and
implements it for both LuaSandbox and LuaStandalone), which takes a PHP
callable and returns a Lua function wrapping it.
Note that fallback code is included so this does not depend on
I2e552799.
Change-Id: Ic0a98eec7cc17ef4b1acee032c0f42d617b998d2
There's no reason LuaStandalone cannot handle NaN and Inf.
Also, add some unit tests to check this.
Change-Id: I8570242a792e212489ad24dfc04fb1f2940190a5
* string.format() truncates the string at a null character, causing a
deadlock when Lua attempts to send null characters to PHP. Use
concatenation instead.
* Added test.
* Fixed an error reporting issue in the console, which I happened to
notice at the same time as the above bug.
Change-Id: I2e6061a04512557492bffbd04bc09ca3bc1d80d6
