2 ms·
Love a good debugging story. Curious if there is a way to narrow the bug down. Looking at the code, it seems it is copying val to counts. It does analogous ari
by koliber 3y ago
Love a good debugging story. Curious if there is a way to narrow the bug down.
Looking at the code, it seems it is copying val to counts. It does analogous arithmetic on val an on counts, and since they both should contain the same data, it's surprising that the result of the arithmetic does not match.
Can you reorder the code to see if the error is reproducible? Do it only for a diagnostic run, and don't change the actual code. For example, change the first loop into two loops:
for (int i = 0; i < length; i++) {
counts[i] = val[i];
}
long offset = 0;
for (int i = 0; i < length; i++) {
offset += val[i];
}
Perhaps some combination of writing val[i] and immediately reading it causes an issue.
Another variant to try is to add another running counter that mimics the size arithmetic, but in the first loop, and compare the three values to see if you get 2 out of three to match:
long offset = 0;
long size_debug = 0;
for (int i = 0; i < length; i++) {
counts[i] = val[i];
offset += val[i];
size_debug += counts[i];
}
If this does not change the behavior, see if there is a region of the file where size and offset diverge. Maybe it is in a random place. Maybe it's always near the end. Maybe it's localized somehow. How to do this would involve writing a value of offset every X iterations of i, as well as writing the value of size every X iterations of i, and seeing if there is a pattern where they diverge. Do it every 1Gb or so.
If I had to place a long bet, my guess is that somewhere in the first loop, after assigning counts[i] = val[i]; reading from val[i]; does not return the same value. You said it's in the same thread, but we need to admin this is a deep bug, so all bets are off.