LuaJIT2 bug: 'mytable[mystring] or 0' wrongly 0

[Duncan Cross <duncan.cross@...>]

Hi List,

I am currently working on a Lua implementation of the "Diff, Match & Patch"
API [1], based (heavily) on the Javascript version by Neil Fraser. I decided
to try it out with LuaJIT 2.0.0 beta 2, and found that one of the tests was
failing, but not if I called jit.off() first.

I have been investigating and unfortunately it seems like changing almost
anything stops the problem from occurring, so I have not been able to simplify
the test case very much and instead have just added some debug output to the
module and will include the whole thing. I hope that it is reproducible on
other peoples' machines, I have not been able to try it out on anything other
than my own system (Windows Vista laptop, LuaJIT compiled with Visual C++ 2005
Express).

You can get a work-in-progress version of diff_match_patch.lua from:
 http://pastebin.com/f70006a0b

...save it as "diff_match_patch.lua" in a require-able path and run this short
test script from the LuaJIT command prompt:

 local dmp = require 'diff_match_patch'
 jit.off()
 dmp.settings{Match_Distance=100, Match_Threshold=0.5}
 assert(6 == dmp.match_bitap('abcdefghijk', 'fgh', 6))
 assert(6 == dmp.match_bitap('abcdefghijk', 'fgh', 1))
 assert(5 == dmp.match_bitap('abcdefghijk', 'efxhi', 1))
 assert(3 == dmp.match_bitap('abcdefghijk', 'cdefxyhijk', 6))

What should happen is that you will see a lot of pairs of values separated by a
double-dash, e.g.:

 --
 1
 1
 --
 2
 2
 --

Each pair of values should be either the same number twice, or nil and 0.
Hopefully, this is the output you will get at this point. None of the
assertions in the code should fail.

Now comment out the jit.off() line, and run it again. (You may need to start
a new session of the command prompt, I'm not sure.) What happens for me is
the final assertion fails, and reading back the pairs of values, in a lot of
cases towards the end, the first number is not zero or nil but the second
value *is* zero (which shouldn't be possible):

 --
 64
 0
 --
 128
 0
 --
 256
 0
 --
 512
 0
 --
 . . .
 luajit.exe: runtests.lua:7: assertion failed!

Look at the for-loop starting at line 1660 of diff_match_patch.lua to see where
these values get output. (In fact they are written to a table first then output
outside of the loop - using print() or string concatenation inside the loop
stops the behaviour from happening for me.)

-Duncan

[1] http://google-diff-match-patch.googlecode.com/