Barf
Expert
Joined: 24 Oct 2008
Posts: 1414
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). |
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
File Section
Wiki
