Closed Jean-Romain closed 6 years ago
And we have another one with GCC
==48816==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60300005add2 at pc 0x7f6c33cba36e bp 0x7ffed8038b90 sp 0x7ffed8038338
READ of size 19 at 0x60300005add2 thread T0
#0 0x7f6c33cba36d (/lib64/libasan.so.4+0x5136d)
#1 0x7f6c301ea457 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (/lib64/libstdc++.so.6+0x128457)
#2 0x7f6c21c14356 in vlrsreader(LASheader*) /data/gannet/ripley/R/packages/tests-gcc-SAN/rlas/src/readheader.cpp:215
In my opinion:
no_data should be replaced at the same place it is done while reading (it is not done at the moment, no? couldn't find it). It can be done either in the R part or in the Rcpp part, anyway NA_interger in R and Rcpp is the mininimum integer value, i.e. -2^31. One may be faster than the other, I never tried: in R it would be just after the checkers for writeLAS.R, but I couldn't find the right place in readLAS.R as the header and data are read separatly. In C++ it would stand just before the scaling of the data for writeLAS.cpp, but I could not find a good place in rlasstreamer...
option should be fixed into the c++ writeLAS.cpp and should not snd error in checker, e.g. a minimum value is given --> the corresponding option flag should be set to TRUE just before writing. This way you would avoid any sort of error and the checks with it, and wouldn't bother user with problems that are not of his responsability.
Cheers
Florian
This commit make the code much more readable and ensure that NA will never be written in the file. I hope it fixes clang-ASAN and clang-USBAN errors.
gcc-ASAN still don't like std::string(reinterpret_cast< char const* >(U8*))
This commit disable some features. I'm not able to convert U8 into string without using `reinterpret_cast< char const >`. If these lines are really responsible of the ASAN error I'm not able to fix I remove the support for now.
@floriandeboissieu
I released
rlas
. Every regular tests are good but I received the following email from Prof. Bryan RipleyLooking in the logs, it is an error with the memory sanitizer. ASAN and USBAN are diffcult tools to use. I'm definitively not able to reproduce and
rhub::check_with_sanitizers
is ok. Thus it is impossible to reproduce.The good new is that the error on CRAN is informative:
So in my opinion it is related to
no_data
. I'm not fully comfortable with this part. You are the main author of this code. Could you please check that.NA
by theno_data
value (l.363)? And vis versa or is it managed internally by LASlib. I guess we have to do it manually.no_data
(l.144)?The support of
NA
is maybe not entirely correct.