Barf Expert
Joined: 24 Oct 2008 Posts: 1415 Location: Munich, Germany |
Posted: Sun Jul 13, 2014 9:33 am Post subject: Bug in ExchangeIR/FindRepeat, C and Java versions |
|
|
While working in IrScrutinizer, I found out that if the IR sequence
Code: | 8937,4507,573,573,573,573,573,573,573,573,573,573,573,573,573,573,
573,1667,573,1667,573,1667,573,1667,573,1667,573,1667,573,1667,573,1667,
573,1667,573,573,573,1667,573,573,573,573,573,573,573,573,573,573,573,573,
573,1667,573,573,573,1667,573,1667,573,1667,573,1667,573,1667,573,1667,
573,38743,8937,2267,573,96011,4507,104,1068,782,52,208,26,72327,573,96011,
8937,2267,573,96011 |
causes the Java version of ExchangeIR/FindRepeat, called RepeatFinder, to misbehave. It will cause the function
Code: |
protected boolean equalTimes(int[] t1, int offset1, int[] t2, int offset2, int duration_count) {
for (int i = 0; i < duration_count; i++) {
if (!equalTimes(t1[i + offset1], t2[i + offset2]))
...
|
to be called with t1 and t2 integer arrays of length 86, offset1 = 68, offset2 = 84, duration_count = 14. As is easily seen, three iterations into the loop, and this will try to access t2 outside of its allocated area, throwing an ArrayIndexOutOfBoundsException. I tried the original C version, and it shows exactly the same behavior, just, as C (C++ really), it does not throw an exception, but just gets "something" (undefined) from memory, and happily computes on that. (With bad luck, segmentation errors may result though.) Since (approximate) equality is tested, likely the function will return false.
The quick fix I will implement in the Java version is just to catch the exception, and return false; it is probably fairly innocent (equality was to be tested). |
|