Closed dipterix closed 2 years ago
Also the following statement is wrong,
Changing to
if(part == 0) {
part_nelem = (*cum_part) * unit_partlen;
} else {
part_nelem = (*cum_part - *(cum_part - 1)) * unit_partlen;
}
if( part == part_start ) {
read_start = skip_start;
} else {
read_start = 0;
}
The code exists in both load.cpp
and save.cpp
... Needs to update both.
The new commit https://github.com/dipterix/filearray/commit/21bc2081a58dd3431ea87c3d02e526a2ee253393 fixes the issues (filearray 0.1.4.9000
)
Testing script:
library(filearray)
filearray_threads(1)
testthat::test_dir('tests')
testthat::test_examples('.')
# loadNamespace("bit64")
set.seed(1)
x1 <- filearray_create(tempfile(), dimension = c(100,20,3))
x1[] <- rnorm(6000)
x2 <- filearray_create(tempfile(), dimension = c(100,20,3))
x2[] <- rnorm(6000)
# Add two arrays
output <- filearray_create(tempfile(), dimension = c(100,20,3))
fmap(list(x1, x2), function(input){
print(length(input[[1]]))
input[[1]] + input[[2]]
}, output, .input_size=8100)
print(range(x1[] + x2[] - output[]))
# R -d "valgrind --tool=memcheck --leak-check=full" -f tmp.R | grep ==
Memory check result:
> # R -d "valgrind --tool=memcheck --leak-check=full" -f tmp.R | grep ==
==40499==
==40499== HEAP SUMMARY:
==40499== in use at exit: 178,803,840 bytes in 20,419 blocks
==40499== total heap usage: 1,294,546 allocs, 1,274,127 frees, 1,198,582,624 bytes allocated
==40499==
==40499== LEAK SUMMARY:
==40499== definitely lost: 0 bytes in 0 blocks
==40499== indirectly lost: 0 bytes in 0 blocks
==40499== possibly lost: 0 bytes in 0 blocks
==40499== still reachable: 178,803,840 bytes in 20,419 blocks
==40499== of which reachable via heuristic:
==40499== newarray : 4,264 bytes in 1 blocks
==40499== suppressed: 0 bytes in 0 blocks
==40499== Reachable blocks (those to which a pointer was found) are not shown.
==40499== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==40499==
==40499== For lists of detected and suppressed errors, rerun with: -s
==40499== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Closing this issue as the fix has been deployed (>= 0.1.5). The version has been submitted to CRAN.
Reported by
clang-UBSAN
from CRANThe bug is caused by the following code:
https://github.com/dipterix/filearray/blob/c99c1229f557c0ca9493082ad40775087fe970ad/src/save.cpp#L49-L50
When the buffer size exceed array lengths,
slice_idx2
may exceednparts
(number of partitions), and pointercum_part
will go beyond the end of the vector (that's why*cum_part
becomes4616189618054758400
)The solution could be instead of calculating
skip_end
, simply replace the following codehttps://github.com/dipterix/filearray/blob/c99c1229f557c0ca9493082ad40775087fe970ad/src/save.cpp#L78-L81
to: