Wikimedia Bugzilla is closed!

I've created a reduced version of the test that reveals the bug, at https://test2.wikipedia.org/wiki/Module:71061 and https://test2.wikipedia.org/wiki/Module:71061/doc .

I've tracked this down to a bug in LuaSandbox. When an array from LuaSandbox is passed to count() under HHVM, count() returns 4294967295 instead of the array's actual size.

I think it has to do with ArrayData::m_size being a uint32_t but getting initialized to -1 in hphp/runtime/base/proxy-array.cpp:67.

(In reply to Jackmcbarn from comment #2)
> I've tracked this down to a bug in LuaSandbox. When an array from LuaSandbox
> is passed to count() under HHVM, count() returns 4294967295 instead of the
> array's actual size.

With Jackmcbarn's test script, this manifests in the size of $capt at the top of Scribunto_LuaUstringLibrary::ustringGmatchCallback sometime ballooning to 4294967295.

Created attachment 16534 [details]
Python script based on Jackmcbarn's test case

This script will make three identical requests to the Scribunto API. This output is typical on osmium:

Request #1 (duration: 2.02s):
PHP = "(Č)"
done

Request #2 (duration: 111.30s):
done

Request #3 (duration: 0.34s):
PHP = "(Č)"
done


Notice that the first and third requests are fine, and that the second requests takes unusually longer to process.

I am working on a fix now. The problem is apparently CodeGenerator::cgCountArray(). Probably everything that uses ArrayData::offsetofSize() is broken.

Reduced test case:

<?php

$lua = 'return test.test({0})';

function test( $x ) {
	return array(count( $x ));
}

$sb = new LuaSandbox;
$sb->registerLibrary( 'test', array('test'=>'test'));
$ret = $sb->loadString( $lua )->call();
print "$ret[0]\n";
$sb = null;

https://github.com/facebook/hhvm/pull/3811

(In reply to Tim Starling from comment #7)
> https://github.com/facebook/hhvm/pull/3811

Nice; thanks.