Wikimedia Bugzilla is closed!

There is a sporadic bug in the Lua string handling functions:

string.find
string.gmatch

and possibly others.

It is characterized by a relatively rare intermittent failure.  I've worked up a test case that attempts many find operations on long strings, and ultimately generates an error maybe 30% of the time.

http://test2.wikipedia.org/wiki/StringFailures_Test

To be clear, some times the parser renders this code correctly, and sometimes it generates an error.  Which outcome happens is unpredictable.  Simply doing action=purge will allow one to see the error appear and disappear.  Because it is intermittent with a low rate one may need to purge the page several times to see the error.

When string.find encounters this error it generates:

Lua error: attempt to perform arithmetic on a table value.

Backtrace:
[C]: in function "find"
Module:StringFailures:13: in function "chunk"
mw.lua:424: in function "chunk"

When string.gmatch hits an error, _the server error page is shown_.

Specifically "Our servers are currently experiencing a technical problem...", with the details: 

Request: POST http://test2.wikipedia.org/w/index.php?title=StringFailures_Test&action=submit, from 10.64.0.139 via cp1018.eqiad.wmnet (squid/2.7.STABLE9) to 10.2.2.1 (10.2.2.1)

Error: ERR_ZERO_SIZE_OBJECT, errno [No Error] at Wed, 27 Feb 2013 22:08:59 GMT


I don't know what is causing this problem but I would guess that it is some kind of buffer overrun or allocation problem that is causing the string functions to look at or manipulate memory beyond the end of the string.

It appears that the corresponding functions mw.ustring.find and mw.ustring.gmatch do not ever generate this error.  The UTF-8 versions are somewhat slower, but as far as I have been able to determine they work correctly all of the time.

Given the above, I had a suspicion that the error might be related to sending UTF-8 values to the string functions; however, that does not appear to be the case.  The error condition will occur with either ASCII or UTF-8 data.

For the moment, using only the mw.ustring functions appears to be a viable workaround.