[R-pkg-devel] How to identify what flags "Additional Issues" for UBSAN

[Kenny, Christopher]

Thanks to each of you. Looks like we have a simple solution by just checking remaining, as suggested. I appreciate pointing out that it was a runtime error, so it definitely occurred and was not just a theoretical concern.

Thanks,
Chris
________________________________
From: Hugh Parsonage <hugh.parsonage using gmail.com>
Sent: Thursday, March 23, 2023 7:17 AM
To: Ivan Krylov <krylov.r00t using gmail.com>
Cc: Kenny, Christopher <christopherkenny using fas.harvard.edu>; r-package-devel using r-project.org <r-package-devel using r-project.org>
Subject: Re: [R-pkg-devel] How to identify what flags "Additional Issues" for UBSAN

In line https://github.com/alarm-redist/redist/blob/f1ed042841469456c1d8c149092bc818e2a5c1a5/src/wilson.cpp#L165

int max_try = 50 * remaining * ((int) std::log(remaining));

you need to ensure remaining > 0.  At some point it became -1.

On Thu, 23 Mar 2023 at 22:07, Ivan Krylov <krylov.r00t using gmail.com> wrote:
>
> � Wed, 22 Mar 2023 15:51:54 +0000
> "Kenny, Christopher" <christopherkenny using fas.harvard.edu> �����:
>
> > Is there an easy way to identify what is causing the flag?
>
> Unfortunately, it's _all_ the sanitizer errors.
>
> > wilson.cpp:165:34: runtime error: signed integer overflow:
> > -2147483648 * -1 cannot be represented in type 'int'
>
> > However, my understanding is that these errors should be expected, as
> > the input is controlled from within the package and checking for
> > these types of errors in every loop would push against the purpose of
> > using C++ for performance here.
>
> You'd be right to think that signed integer overflow just wraps around
> on modern CPUs with no adverse effects on the rest of the execution.
> Unfortunately, you'd also need to convince the C++ optimiser, and it's
> currently allowed to think otherwise.
>
> In C++, signed integer overflow (and other similar errors, such as
> casing NaN to an integer) is undefined behaviour, which, according to
> the standard, means that anything can happen after that, ranging from
> nothing out of order to a crash and also to silent corruption of
> important research results. Other languages define integer overflow to
> have a more limited impact (wrap the value around or at least guarantee
> a crash), but not C and C++. [*]
>
> Thankfully, I only see one spot where you encounter UB, in
> src/wilson.cpp line 165, which should be relatively easy to fix by
> adjusting your strategy for calculating the maximum number of tries.
> (Do you get a NaN when `remaining` is -1? Why is it -1? Or is it 0?)
>
> --
> Best regards,
> Ivan
>
> [*]
> Some old gcc version used to launch the game Nethack when certain kinds
> of UB were encountered. The situation has improved in some ways since
> that and worsened in others: modern C and C++ compilers, especially
> Clang, use UB to guide their optimisation efforts, so if the optimiser
> can prove "if A is true then UB happens", it optimises with the
> assumption that A is false.
>
> Combined with optimizer bugs, this understanding of undefined
> behaviour may lead to funny situations where the inability of the
> compiler to prove certain facts about the program leads to
> mathematically inconsistent results:
> https://blog.regehr.org/archives/140
>
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

	[[alternative HTML version deleted]]