Work around Annoy UBSAN issues #50

jlmelville · 2020-02-23T20:11:26Z

The latest submission of uwot to CRAN has been rejected due to the UBSAN issues inherited from RcppAnnoy (the UBSAN check is currently accessible via a link on https://cran.r-project.org/web/checks/check_results_uwot.html):

Thanks, it is your choice to use RcppAnnoy, so you have to work around the issues. The use of undefined behaviour is not compatible with the CRAN policy.

Please fix and resubmit.

If this decision isn't reconsidered, I imagine that this is likely to see uwot being removed from CRAN shortly.

The UBSAN issue is also present in RcppAnnoy itself, not uwot's specific use of the package (as far as I can tell anyway): https://cran.r-project.org/web/checks/check_results_RcppAnnoy.html and is due to how the underlying Annoy library is written. It's not going to get fixed because it's Annoy working as designed. It's not clear to me at the moment if this means RcppAnnoy will also be removed from CRAN or what has changed in policy since the last submission of uwot (or indeed of RcppAnnoy).

At any rate, I grow weary of the ban-hammer lottery uwot enters every time I want to update the package on CRAN. The obvious solution is to stop using Annoy. The upside would be:

no more UBSAN issues hanging over uwot.
Annoy is able to write indices that are too large for it to read back in, so that would remove an error path that I am unable to detect until it's too late (and lots of time and computation has been expended).

The obvious downsides are:

there isn't a good replacement for Annoy.
it will break backwards compatibility with any previously saved models.

RcppHNSW is a possible alternative, but it supports fewer metrics than Annoy and is a lot slower.

I do want to get on with rnndescent, the upsides of which are:

as a translation of pynndescent, it would be closer to the behavior of the nearest neighbor routines used in UMAP.
I can add more metrics support.
I can eventually add sparse matrix support.

A big downside is:

Nearest neighbor descent doesn't build an index, so the saved model needs to include the entire
dataset.

Other downsides that emerge from the fact that I am writing the package, so inevitably:

it'll take ages to get done.
it'll be slower than Annoy.
it will have C++ issues that crash your session.
it will have multi-threading/R API issues that crash your session.
other bugs.

The text was updated successfully, but these errors were encountered:

LTLA · 2020-02-23T20:22:40Z

Crap. BiocNeighbors will also be affected if RcppAnnoy goes down.

It's not going to get fixed because it's Annoy working as designed.

Perhaps we can change that? I can't imagine @eddelbuettel would be too happy about this either.

eddelbuettel · 2020-02-23T20:26:29Z

Dang. I do of course get the UBSAN warnings too for RcppAnnoy itself but so far was allowed to hand-wave them away each and every time mentioning that they are by design

@erikbern Any chance we could have an opt-out / slower alternative? See the two links (in red) off this page: https://cloud.r-project.org/web/checks/check_results_RcppAnnoy.html

@LTLA @jlmelville Very worst case: could it become a Suggests: package and we keep it on a drat repo off CRAN?

LTLA · 2020-02-23T20:34:10Z

Very worst case: could it become a Suggests: package and we keep it on a drat repo off CRAN?

Unfortunately, that wouldn't be possible for me; I compile against the headers in RcppAnnoy, so it's a hard dependency from the perspective of BiocNeighbors. On the plus side, Bioconductor doesn't do UBSAN checks, so I could get away with just stuffing the headers into my src and using them locally. But that is a very unsatisfying solution and it doesn't help uwot.

eddelbuettel · 2020-02-23T20:45:26Z

Just thinking out loud: could we do a poor man's version that doesn't assign an array of size one and knowingly writes outside of boundaries, but a std::vector<T> that resizes as needed ?

jlmelville · 2020-02-23T21:35:43Z

Previously, saying uwot inherits the UBSAN from RcppAnnoy was enough to get the submission approved, so I did ask for some clarification on what this all means for RcppAnnoy (in the no-doubt vain hope they will say "really? oh, ok, go on then"). In my experience "please fix and resubmit" is the end of the line for the current submission, so I don't know if I will get a reply. If this has resulted in the Eye of Sauron being turned upon RcppAnnoy prematurely, I apologise.

@eddelbuettel: in terms of replacing the array with a std::vector, are you thinking about this as a an addition to RcppAnnoy using a macro similar to __ERROR_PRINTER_OVERRIDE__ and/or then offering it upstream? I would be happy to take this discussion to the RcppAnnoy repo or wherever you think is most appropriate. (Edited: to clarify, I would be happy to attempt a PR or the start of one to share the burden of any proposed fix).

eddelbuettel · 2020-02-23T21:58:15Z

"It's complicated." I knew where CRAN is coming from, yet it is tired. I have several packages that 'stretch the limit' somewhat. Rcpp, RInside, RcppAnnoy, ... all get warnings this way, but they always have and it isn't always possible to rewrite.

Here, it just occured to me a possibly 'simple enough yet safer' approach. I'd be game for all of trying to build that (as a derived version of Annoy, maybe?) and write a quick paper about the tradeoff and speed impact, assuming we get it done. Obviously with full credit to all things Annoy that get re-used.

@erikbern Interested in helping / getting involved?

erikbern · 2020-02-23T22:23:54Z

@erikbern Any chance we could have an opt-out / slower alternative? See the two links (in red) off this page: https://cloud.r-project.org/web/checks/check_results_RcppAnnoy.html

I'm not following. When I look at the compiler output, it looks like the error is that alloca is not being defined? https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/RcppAnnoy-00install.html

So maybe there's just some header file that needs to get included or something?

jlmelville · 2020-02-23T22:27:27Z

@erikbern, the undefined behavior is the issue, which is accessed via the gcc-UBSAN link. You can see it at:

https://www.stats.ox.ac.uk/pub/bdr/memtests/gcc-UBSAN/RcppAnnoy/RcppAnnoy-Ex.Rout

(the lack of a Solaris build is a separate issue).

eddelbuettel · 2020-02-23T22:29:29Z

Sorry for being somewhat vague.

UBSAN issue with clang

Link https://www.stats.ox.ac.uk/pub/bdr/memtests/clang-UBSAN/RcppAnnoy/RcppAnnoy-Ex.Rout
Partial quote

> # PERFORMING ANNOY SEARCH ------------------------------------------------------
> 
> # Retrieve 5 nearest neighbors to item 0
> # Returned as integer vector of indices
> a$getNNsByItem(0, 5)
[1]  0 23 88 72 81
> 
> # Retrieve 5 nearest neighbors to item 0
> # search_k = -1 will invoke default search_k value of n_trees * n
> # Return results as list with an element for distance
> a$getNNsByItemList(0, 5, -1, TRUE)
/data/gannet/ripley/R/test-clang/Rcpp/include/Rcpp/internal/caster.h:30:25: runtime error: -1 is outside the range of representable values of type 'unsigned long'
    #0 0x7f1d43d2ed73 in unsigned long Rcpp::internal::caster<double, unsigned long>(double) /data/gannet/ripley/R/test-clang/Rcpp/include/Rcpp/internal/caster.h:30:25
    #1 0x7f1d43d2ed73 in unsigned long Rcpp::internal::primitive_as<unsigned long>(SEXPREC*) /data/gannet/ripley/R/test-clang/Rcpp/include/Rcpp/as.h:39:21
    #2 0x7f1d43d66661 in unsigned long Rcpp::internal::as<unsigned long>(SEXPREC*, Rcpp::traits::r_type_primitive_tag) /data/gannet/ripley/R/test-clang/Rcpp/include/Rcpp/as.h:44:20
    #3 0x7f1d43d66661 in unsigned long Rcpp::as<unsigned long>(SEXPREC*) /data/gannet/ripley/R/test-clang/Rcpp/include/Rcpp/as.h:152:16
    #4 0x7f1d43d66661 in Rcpp::InputParameter<unsigned long>::operator unsigned long() /data/gannet/ripley/R/test-clang/Rcpp/include/Rcpp/InputParameter.h:34:38
    #5 0x7f1d43d66661 in Rcpp::CppMethod4<Annoy<int, float, Euclidean, Kiss64Random>, Rcpp::Vector<19, Rcpp::PreserveStorage>, int, unsigned long, unsigned long, bool>::operator()(Annoy<int, float, Euclidean, Kiss64Random>*, SEXPREC**) /data/gannet/ripley/R/test-clang/Rcpp/include/Rcpp/module/Module_generated_CppMethod.h:375:78
    #6 0x7f1d43d40ec3 in Rcpp::class_<Annoy<int, float, Euclidean, Kiss64Random> >::invoke_notvoid(SEXPREC*, SEXPREC*, SEXPREC**, int) /data/gannet/ripley/R/test-clang/Rcpp/include/Rcpp/module/class.h:234:23
    #7 0x7f1d4408fab4 in CppMethod__invoke_notvoid(SEXPREC*) /tmp/Rtmpx8yYBz/R.INSTALL4d831dbc1bd4/Rcpp/src/module.cpp:220:19
    #8 0x6e04e8 in do_External /data/gannet/ripley/R/svn/R-devel/src/main/dotcode.c:576:11
    #9 0x83ce20 in Rf_eval /data/gannet/ripley/R/svn/R-devel/src/main/eval.c:791:9
    #10 0x8aa022 in do_begin /data/gannet/ripley/R/svn/R-devel/src/main/eval.c:2471:10
    #11 0x83c823 in Rf_eval /data/gannet/ripley/R/svn/R-devel/src/main/eval.c:763:12
    #12 0x89f393 in R_execClosure /data/gannet/ripley/R/svn/R-devel/src/main/eval.c
    #13 0x89c2fa in Rf_applyClosure /data/gannet/ripley/R/svn/R-devel/src/main/eval.c:1779:16
    #14 0x83d04b in Rf_eval /data/gannet/ripley/R/svn/R-devel/src/main/eval.c:811:12
    #15 0x977756 in Rf_ReplIteration /data/gannet/ripley/R/svn/R-devel/src/main/main.c:264:2
    #16 0x97bcd0 in R_ReplConsole /data/gannet/ripley/R/svn/R-devel/src/main/main.c:314:11
    #17 0x97bab5 in run_Rmainloop /data/gannet/ripley/R/svn/R-devel/src/main/main.c:1113:5
    #18 0x4da36a in main /data/gannet/ripley/R/svn/R-devel/src/main/Rmain.c:29:5
    #19 0x7f1d54bfef42 in __libc_start_main (/lib64/libc.so.6+0x23f42)
    #20 0x43037d in _start (/data/gannet/ripley/R/R-clang-SAN/bin/exec/R+0x43037d)

SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /data/gannet/ripley/R/test-clang/Rcpp/include/Rcpp/internal/caster.h:30:25 in 
$item
[1]  0 23 88 72 81

$distance
[1] 0.0000000 0.7270762 0.8223635 0.8352855 0.9268327

>

UBSAN issue with gcc

Link https://www.stats.ox.ac.uk/pub/bdr/memtests/gcc-UBSAN/RcppAnnoy/RcppAnnoy-Ex.Rout
Partial quote

> # Load 100 random vectors into index
> for (i in 1:100) a$addItem(i - 1, runif(vector_size)) # Annoy uses zero indexing
../inst/include/annoylib.h:872:11: runtime error: index 1 out of bounds for type 'float [1]'
    #0 0x7f601cf651ab in bool AnnoyIndex<int, float, Euclidean, Kiss64Random>::add_item_impl<float const*>(int, float const* const&, char**) ../inst/include/annoylib.h:872
    #1 0x7f601cf651ab in AnnoyIndex<int, float, Euclidean, Kiss64Random>::add_item(int, float const*, char**) ../inst/include/annoylib.h:852
    #2 0x7f601cf651ab in Annoy<int, float, Euclidean, Kiss64Random>::addItem(int, Rcpp::Vector<14, Rcpp::PreserveStorage>) /data/gannet/ripley/R/packages/tests-gcc-SAN/RcppAnnoy/src/annoy.cpp:58
    #3 0x7f601cf90630 in Rcpp::CppMethod2<Annoy<int, float, Euclidean, Kiss64Random>, void, int, Rcpp::Vector<14, Rcpp::PreserveStorage> >::operator()(Annoy<int, float, Euclidean, Kiss64Random>*, SEXPREC**) /data/gannet/ripley/R/test-4.0/Rcpp/include/Rcpp/module/Module_generated_CppMethod.h:215
    #4 0x7f601d0c6dda in Rcpp::class_<Annoy<int, float, Euclidean, Kiss64Random> >::invoke_void(SEXPREC*, SEXPREC*, SEXPREC**, int) /data/gannet/ripley/R/test-4.0/Rcpp/include/Rcpp/module/class.h:212
    #5 0x7f601d72d3f9 in CppMethod__invoke_void(SEXPREC*) /tmp/RtmpgEt2jx/R.INSTALL8a946a8463c1/Rcpp/src/module.cpp:200
    #6 0x568fce in do_External /data/gannet/ripley/R/svn/R-devel/src/main/dotcode.c:576
    #7 0x66bc58 in Rf_eval /data/gannet/ripley/R/svn/R-devel/src/main/eval.c:791
    #8 0x674e08 in do_begin /data/gannet/ripley/R/svn/R-devel/src/main/eval.c:2471
    #9 0x66b58c in Rf_eval /data/gannet/ripley/R/svn/R-devel/src/main/eval.c:763
    #10 0x670045 in R_execClosure /data/gannet/ripley/R/svn/R-devel/src/main/eval.c:1853
    #11 0x672764 in Rf_applyClosure /data/gannet/ripley/R/svn/R-devel/src/main/eval.c:1779
    #12 0x63d211 in bcEval /data/gannet/ripley/R/svn/R-devel/src/main/eval.c:7022
    #13 0x680785 in R_compileAndExecute /data/gannet/ripley/R/svn/R-devel/src/main/eval.c:1479
    #14 0x681039 in do_for /data/gannet/ripley/R/svn/R-devel/src/main/eval.c:2260
    #15 0x66b58c in Rf_eval /data/gannet/ripley/R/svn/R-devel/src/main/eval.c:763
    #16 0x6e99ad in Rf_ReplIteration /data/gannet/ripley/R/svn/R-devel/src/main/main.c:264
    #17 0x6e99ad in Rf_ReplIteration /data/gannet/ripley/R/svn/R-devel/src/main/main.c:200
    #18 0x6ea0a8 in R_ReplConsole /data/gannet/ripley/R/svn/R-devel/src/main/main.c:314
    #19 0x6ea1f4 in run_Rmainloop /data/gannet/ripley/R/svn/R-devel/src/main/main.c:1113
    #20 0x419388 in main /data/gannet/ripley/R/svn/R-devel/src/main/Rmain.c:29
    #21 0x7f602dbb0f42 in __libc_start_main (/lib64/libc.so.6+0x23f42)
    #22 0x41bacd in _start (/data/gannet/ripley/R/gcc-SAN/bin/exec/R+0x41bacd)

>

I had forgotten that each directory contained several files, sorry about that.

But it is otherwise a clear case: UBSAN just finds what it designed to find ... we are out of bounds here by design. Sigh. Can't win that unless we get a whitelist. Which we won't ...

erikbern · 2020-02-23T22:32:48Z

@erikbern, the undefined behavior is the issue, which is accessed via the gcc-UBSAN link. You can see it at:

https://www.stats.ox.ac.uk/pub/bdr/memtests/gcc-UBSAN/RcppAnnoy/RcppAnnoy-Ex.Rout

(the lack of a Solaris build is a separate issue).

Got it, I see the issue. It's probably not super hard to fix though, although it's a bit janky. Two options off the top of my head

Make the array some large number instead of length 1.
Rewrite all access of the form node->v[i] to something like get_index(node, i) or maybe get_vector(node)[i].

I don't quite know what's going on here and how to repro it but let me know what you think of the above

eddelbuettel · 2020-02-23T22:36:57Z

Spot on!

It shouldn't be hard to repro, possibly outside of R too, as we have some instrumentation. Eg https://builder.r-hub.io/ is build service that has an UBSAN variant, and there are some Docker containers.

I only ever looked at this briefly (though repeatedly :-). The array is for the number of child nodes, correct? What is a 'safe enough' upper bound, how much would we loose in performance and/or memory use, and is picking std::vector<T> as I hinted clever enough because it also has .resize() semantics?

erikbern · 2020-02-23T22:47:19Z

I put together a quick PR that maybe fixes it in a dumb way? Idk take a look :)

jlmelville · 2020-02-24T03:31:40Z

The good news: @erikbern's fix in spotify/annoy#455 does remove one set of UBSAN issues.

The less good news: there's still an UBSAN issue with misalignment of 8 byte ints in the Hamming code (see spotify/annoy#456). But it's progress!

jlmelville · 2020-02-24T04:38:29Z

Just to confirm this explicitly @eddelbuettel: I commented out the Hamming tests in my local checkout of RcppAnnoy, resubmitted to rhub::check_with_sanitizers(), and got back an OK green email from rhub, which to me confirms that the problem is now localized to the Hamming distance.

For uwot, the worst-case scenario now would be to remove Hamming support temporarily.

jlmelville · 2020-02-24T06:18:21Z

Well this is weird. I have just tried to repeatedly re-trigger the memory alignment complaint and I can't.

I even did a fresh checkout of RcppAnnoy, confirmed the runtime error: index 1 out of bounds for type 'float [1]' appeared, then replaced with the current Annoy master of annoylib.h directly and repeated rhub::check_with_sanitizers(), and now there are no UBSAN errors. According to the output, the Hamming tests are definitely running.

@eddelbuettel, can you confirm any of this either way?

erikbern · 2020-02-24T12:45:13Z

The memory alignment probably only triggers stochastically when the allocated block of memory is not a multiple of 8. My guess is most of the time it will be

eddelbuettel · 2020-02-24T12:49:05Z

@jlmelville I haven't been able to confirm besides submitting to rhub, which I only did with the very first (incomplete) PR change.

Edit: Also, that rhub builder is wonky. Sometimes I see error in the headline summary but OKs in the text.

Anyway, big thanks already to Erik. This is a huge step forward.

eddelbuettel · 2020-02-24T13:26:36Z

But looks good. Created a branch, updated upstream annoylib.h (and mmap.h) and it looks good so far...

eddelbuettel · 2020-02-24T21:05:52Z

Quick follow-up. I realized that I had two Rocker containers with SAN/UBSAN, so I triggered a rebuild. One (using clang) is still building, the other (using gcc) finished and I just used it. I copied Rcpp, the previous RcppAnnoy release and a candidate based on yesterday's PR to Annoy into a temp. directory, installed Rcpp and then tested the two RcppAnnoy variants.

Good news: The old behaviour was seen on the older RcppAnnoy and is gone in the new one. Three cheers to @erikbern and a big thank you to @jlmelville for pushing this.

Not so good news: gcc is still whining:

../inst/include/annoylib.h:378:42: warning: taking address of packed member of ‘Minkowski::Node<int, float>’ may result in an unaligned pointer value [-Waddress-of-packed-member]
[...]
../inst/include/annoylib.h:416:29: warning: taking address of packed member of ‘Angular::Node<int, float>’ may result in an unaligned pointer value [-Waddress-of-packed-member]

these pop up a few times for the different metrics. Can we 'unpack' this?

(Goes digging for a bit...)

I guess we could add a #define to suppress this from defining:

#ifndef ANNOY_NODE_ATTRIBUTE
    #ifndef _MSC_VER
        #define ANNOY_NODE_ATTRIBUTE __attribute__((__packed__))
        // TODO: this is turned on by default, but may not work for all architectures! Need to investigate.
    #else
        #define ANNOY_NODE_ATTRIBUTE
    #endif
#endif

Using the empty definition is fine, as you'd expect. So we can wait for CRAN to complain and turn off as needed...

eddelbuettel · 2020-02-26T14:03:45Z

Quick update: Wheels of progress are moving slowly at CRAN, took a day for them yesterday to get back to me ... only to say that I am still naughty for using alloca() in a non-portable. But there is a trivial fix in Writing R Extensions (that they were kind enough to remind me of) so I added that, and will PR it up to annoy too. Five lines of simple #include/#define logic affecting really only Solaris...

eddelbuettel · 2020-02-27T16:18:45Z

New RcppAnnoy on CRAN. Let's see how it does.

One new/remaining clang UBSAN issue per email from CRAN. I opened an issue over at RcppAnnoy.

jlmelville · 2020-02-27T17:51:42Z

Thank you for all the time you have spent on this @eddelbuettel. I have got a rocker image of r-devel-usban-clang running locally if I can help with any of this, but I have moved the immediate discussion over to eddelbuettel/rcppannoy#56.

eddelbuettel · 2020-02-27T18:13:14Z

Yes, triggered a refesh of that image a few days ago. Does that trigger the issue? And it is on the R/Rcpp side only so one once @erikbern can just say "you guys..." ? Greetings from CPH.

eddelbuettel · 2020-02-27T18:14:26Z

Looks much better already at https://cloud.r-project.org/web/checks/check_results_RcppAnnoy.html

jlmelville · 2020-02-27T18:26:44Z

@eddelbuettel the rocker image does not trigger any complaints for me at the moment, but I suspect I may not have correctly invoked R or R CMD CHECK so that's a work in progress.

eddelbuettel · 2020-02-27T18:32:26Z

Remember you must use RD as R is the vanilla one. Not the greatest UI I ever did ...

jlmelville · 2020-02-28T06:31:22Z

Thank you for the pointer @eddelbuettel, it's been a while since I have run the rocker container and I was on the way out to my day job this morning. I got a bit further tonight but I have admitted defeat for the evening. For the record, I ran:

docker run --cap-add SYS_PTRACE -ti rocker/r-devel-ubsan-clang bash
# in the container
git clone https://github.com/eddelbuettel/rcppannoy.git
cd rcppannoy
RD
# In R: would it have been better to use /usr/local/bin/Rscriptdevel?
install.packages(c("Rcpp", "tinytest"))
# Back in the shell
RD CMD build .
RD CMD check --as-cran RcppAnnoy_0.0.15.tar.gz

Unfortunately I get the error:

  unable to load shared object '/usr/local/lib/R/site-library/Rcpp/libs/Rcpp.so':
  /usr/local/lib/R/site-library/Rcpp/libs/Rcpp.so: undefined symbol: __asan_option_detect_stack_use_after_return

I wasn't able to satisfactorily resolve this with my googling as a lot of the results want R to be rebuilt with other flags. Could I have used a suitably clang-erized version of the per-package
~/.R/Makevars described at https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Using-Address-Sanitizer?

Rather than waste people's time and flap about ineffectually I will wait to see how the CRAN checks shake out.

jlmelville · 2020-02-28T06:41:55Z

Apart from my inability to work with ASAN, the good news is that I ran uwot through rhub::check_with_sanitizers() with the new version of RcppAnnoy and got no errors due to RcppAnnoy. Hooray!

The bad news: I had forgotten about the UBSAN problems I get from using RcppParallel (the ones uwot get are the same as those that can be seen at https://www.stats.ox.ac.uk/pub/bdr/memtests/gcc-UBSAN/RcppParallel/RcppParallel-Ex.Rout), so uwot's goose is still thoroughly cooked. But that's a problem for another issue.

I will close this issue when RcppAnnoy's CRAN checks all get up to date (hopefully with the UBSAN links disappearing for good). I am also deeply appreciative of the time @eddelbuettel and @erikbern have spent on this.

jlmelville · 2020-03-09T14:43:41Z

CRAN checks show no problems with RcppAnnoy 0.0.16 (and coincidentally an Annoy problem on Windows with writing indices to disk that can't be read back in has been fixed). Once again, great work by @eddelbuettel and @erikbern. A new release of uwot will be submitted to CRAN next Monday.

Closing.

eddelbuettel · 2020-03-09T14:46:20Z

Yes, been checking that too. They were driving me batty over not admitting RcppAnnoy 0.0.16 for 48 or so hours as it still needn't a manual inspection over the remaining-from-0.0.15 UBSAN issue. Should be better now as 0.0.16 is as expected clean as a whistle. Your uwot may hit different codepaths so if you still have issue please bring it to our attention.

eddelbuettel · 2021-11-05T12:44:08Z

a) Please do not hijack old issues.
b) I do not use renv myself.
c) Maybe try the r-help list, or stackoverflow.

erikbern mentioned this issue Feb 23, 2020

Attempt at avoiding falsely flagged buffer overruns spotify/annoy#455

Merged

jlmelville changed the title ~~Stop using Annoy~~ Work around Annoy UBSAN issues Feb 24, 2020

jlmelville mentioned this issue Feb 27, 2020

Error when input data is not of a right-numbered column? #51

Closed

LTLA mentioned this issue Feb 28, 2020

Installation issue, directly related to RcppAnnoy 0.0.15 vs the previous 0.0.14 knncolle/BiocNeighbors#10

Closed

jlmelville mentioned this issue Feb 28, 2020

UBSAN issues: RcppParallel #52

Closed

jlmelville closed this as completed Mar 9, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Work around Annoy UBSAN issues #50

Work around Annoy UBSAN issues #50

jlmelville commented Feb 23, 2020

LTLA commented Feb 23, 2020

eddelbuettel commented Feb 23, 2020

LTLA commented Feb 23, 2020

eddelbuettel commented Feb 23, 2020 •

edited

Loading

jlmelville commented Feb 23, 2020 •

edited

Loading

eddelbuettel commented Feb 23, 2020

erikbern commented Feb 23, 2020 •

edited

Loading

jlmelville commented Feb 23, 2020

eddelbuettel commented Feb 23, 2020

erikbern commented Feb 23, 2020

eddelbuettel commented Feb 23, 2020 •

edited

Loading

erikbern commented Feb 23, 2020

jlmelville commented Feb 24, 2020

jlmelville commented Feb 24, 2020

jlmelville commented Feb 24, 2020

erikbern commented Feb 24, 2020

eddelbuettel commented Feb 24, 2020 •

edited

Loading

eddelbuettel commented Feb 24, 2020

eddelbuettel commented Feb 24, 2020

eddelbuettel commented Feb 26, 2020

eddelbuettel commented Feb 27, 2020

jlmelville commented Feb 27, 2020

eddelbuettel commented Feb 27, 2020

eddelbuettel commented Feb 27, 2020

jlmelville commented Feb 27, 2020

eddelbuettel commented Feb 27, 2020

jlmelville commented Feb 28, 2020

jlmelville commented Feb 28, 2020

jlmelville commented Mar 9, 2020 •

edited

Loading

eddelbuettel commented Mar 9, 2020

eddelbuettel commented Nov 5, 2021

Work around Annoy UBSAN issues #50

Work around Annoy UBSAN issues #50

Comments

jlmelville commented Feb 23, 2020

LTLA commented Feb 23, 2020

eddelbuettel commented Feb 23, 2020

LTLA commented Feb 23, 2020

eddelbuettel commented Feb 23, 2020 • edited Loading

jlmelville commented Feb 23, 2020 • edited Loading

eddelbuettel commented Feb 23, 2020

erikbern commented Feb 23, 2020 • edited Loading

jlmelville commented Feb 23, 2020

eddelbuettel commented Feb 23, 2020

UBSAN issue with clang

UBSAN issue with gcc

erikbern commented Feb 23, 2020

eddelbuettel commented Feb 23, 2020 • edited Loading

erikbern commented Feb 23, 2020

jlmelville commented Feb 24, 2020

jlmelville commented Feb 24, 2020

jlmelville commented Feb 24, 2020

erikbern commented Feb 24, 2020

eddelbuettel commented Feb 24, 2020 • edited Loading

eddelbuettel commented Feb 24, 2020

eddelbuettel commented Feb 24, 2020

eddelbuettel commented Feb 26, 2020

eddelbuettel commented Feb 27, 2020

jlmelville commented Feb 27, 2020

eddelbuettel commented Feb 27, 2020

eddelbuettel commented Feb 27, 2020

jlmelville commented Feb 27, 2020

eddelbuettel commented Feb 27, 2020

jlmelville commented Feb 28, 2020

jlmelville commented Feb 28, 2020

jlmelville commented Mar 9, 2020 • edited Loading

eddelbuettel commented Mar 9, 2020

eddelbuettel commented Nov 5, 2021

eddelbuettel commented Feb 23, 2020 •

edited

Loading

jlmelville commented Feb 23, 2020 •

edited

Loading

erikbern commented Feb 23, 2020 •

edited

Loading

eddelbuettel commented Feb 23, 2020 •

edited

Loading

eddelbuettel commented Feb 24, 2020 •

edited

Loading

jlmelville commented Mar 9, 2020 •

edited

Loading