Re: [lmi] Invalid pointer-pair?

[Vadim Zeitlin]

On Fri, 10 Jun 2022 15:48:17 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> [Here's an ASan complaint that goes away if I use std::array
GC> instead of std::vector const. That's a good change anyway,
GC> so I'll commit it. The stream of consciousness leading up to
GC> that discovery might be interesting, as it seems to indicate
GC> an ASan false positive AFAICT.]

 This definitely looks like a false positive because libstdc++ code is
perfectly straightforward and I don't see how could there be anything wrong
with it: it just passes the pointers returned by begin() and end() of the
provided initializer_list to std::distance and these pointers, in turn, are
just initializer_list::_M_array and _M_array+_M_len, i.e. there is really
no scope for any bug here.

GC> ASan with
GC>   
-fsanitize=address,undefined,leak,pointer-compare,pointer-subtract,float-divide-by-zero,float-cast-overflow,bounds-strict
GC> and
GC>   export 
ASAN_OPTIONS=detect_leaks=0:detect_invalid_pointer_pairs=2:detect_invalid_pointer_pairs=2:strict_string_checks=1:\
GC>     
detect_stack_use_after_return=1:check_initialization_order=1:strict_init_order=1
GC> flags this line:
GC>   /opt/lmi/src/lmi/irc7702_tables_test.cpp:656
GC> as anomalous:
GC> 
GC> ==820578==ERROR: AddressSanitizer: invalid-pointer-pair: 0x7f4c8d37ad00 
0x7f4c8d37a080

 Moreover, the pointer values differ by exactly 3200 bytes, which is the
expected size of an initializer list containing 100 entries of 4 doubles,
each of which takes 8 bytes.

GC> But the code beginning on that line
GC>   /opt/lmi/src/lmi/irc7702_tables_test.cpp:656
GC> is simply:
GC> 
GC> static std::vector<cf_data> const olcf_1980_cso_endt_100 =
GC> {{0.00000, 1                     , 0                     , 
0.06996023573869656} // 0
GC> ,{0.00000, 0.9615384615384615    , 0                     , 
0.07275864516824443} // 1
GC> [...snip many similar lines...]
GC> ,{1.00000, 1.3667620786298768e-05, 1.3141943063748814e-05, 
0.9806435265780128 } // 99
GC> };
GC> 
GC> AFAICS, this direct initialization is a "best practice".
GC> Can that code really be objectionable in any way?

 No.

GC> Wait...let's make it a std::array instead. Now it passes
GC> all those ASan checks. That's actually a desirable change
GC> in its own right, so it's not just a silly workaround.

 Yes, it's a good change, but if this ASAN optional breaks down so easily,
it might explain why it's off by default... I thought this might be related
to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97659 but I'm not really
sure and didn't have time to look into it closer yet. But, again, this bug
seems to indicate that this option isn't really usable with gcc currently
(clang ASAN implementation is rather different, and its libc++ is, of
course, completely different, so it might still be useful there).

 Regards,
VZ

pgpx5OvnHw3ul.pgp
Description: PGP signature