Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Work around Annoy UBSAN issues #50

Closed
jlmelville opened this issue Feb 23, 2020 · 31 comments
Closed

Work around Annoy UBSAN issues #50

jlmelville opened this issue Feb 23, 2020 · 31 comments

Comments

@jlmelville
Copy link
Owner

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.
@LTLA
Copy link
Contributor

LTLA commented Feb 23, 2020

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
Copy link
Contributor

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
Copy link
Contributor

LTLA commented Feb 23, 2020

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
Copy link
Contributor

eddelbuettel commented Feb 23, 2020 •
edited

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
Copy link
Owner Author

jlmelville commented Feb 23, 2020 •
edited

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
Copy link
Contributor

"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
Copy link

erikbern commented Feb 23, 2020 •
edited

@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
Copy link
Owner Author

@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
Copy link
Contributor

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
Copy link

@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

  1. Make the array some large number instead of length 1.
  2. 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
Copy link
Contributor

eddelbuettel commented Feb 23, 2020 •
edited

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 erikbern mentioned this issue Feb 23, 2020
Merged
@erikbern
Copy link

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

@jlmelville
Copy link
Owner Author

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 jlmelville changed the title Stop using Annoy Work around Annoy UBSAN issues Feb 24, 2020
@jlmelville
Copy link
Owner Author

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
Copy link
Owner Author

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
Copy link

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
Copy link
Contributor

eddelbuettel commented Feb 24, 2020 •
edited

@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
Copy link
Contributor

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

@eddelbuettel
Copy link
Contributor

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
Copy link
Contributor

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...

@jlmelville jlmelville mentioned this issue Feb 27, 2020
Closed
@eddelbuettel
Copy link
Contributor

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
Copy link
Owner Author

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
Copy link
Contributor

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
Copy link
Contributor

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

@jlmelville
Copy link
Owner Author

@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
Copy link
Contributor

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

@LTLA LTLA mentioned this issue Feb 28, 2020
Closed
@jlmelville
Copy link
Owner Author

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
Copy link
Owner Author

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 jlmelville mentioned this issue Feb 28, 2020
Closed
@jlmelville
Copy link
Owner Author

jlmelville commented Mar 9, 2020 •
edited

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
Copy link
Contributor

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@eddelbuettel @erikbern @jlmelville @LTLA