Opened 11 months ago

Last modified 5 months ago

#25386 accepted defect

Link Rust Tests to C Dependencies in Tor (allow integration testing from Rust to C)

Reported by: Hello71 Owned by: nickm
Priority: High Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.3.3.1-alpha
Severity: Normal Keywords: rust, tor-test, 033-backport, review-group-34, 034-triage-20180328, 034-included-20180401, 035-removed-20180711
Cc: teor, isis, chelseakomlo, manishearth@… Actual Points:
Parent ID: Points: 3
Reviewer: isis Sponsor: SponsorQ

Description

currently, it is not possible to call C Tor, directly or indirectly, from rust tests. one of the following must be done:

  1. provide rust stubs for all C functions that may be needed for tests (impractical)
  1. test rust functions from C (so we will have C tests calling Rust functions calling C functions)
  1. link C functions into rust doctests (preferred)
  1. never call C-using rust functions in tests (leads to poor test coverage, very bad)

my branch https://cgit.alxu.ca/tor.git/commit/?h=fix-rust-tests implements option 3 poorly. this is a bad solution firstly because it is very ugly, and secondly because it does not properly pass the system linking arguments, e.g. -L/opt/ssl. thirdly, it may hide problems in or cause to be compiled incorrectly dependency crates.

this ticket blocks a number of rust improvements, since of course we would like to actually test the improvements, and doctests are the best way to do it in rust.

Child Tickets

TicketStatusOwnerSummaryComponent
#25605assignedAdd tests for Rust protover::compute_for_old_tor() and C functions it callsCore Tor/Tor
#25841newWrite test for Rust fragile hardeningCore Tor/Tor
#26398closedisisfeature gate testing C code from Rust for nowCore Tor/Tor
#27272closedASan is incompatible with Rust's jemalloc on TravisCore Tor/Tor
#27273reopenedASan fails to link on Travis due to rustc and linker argumentsCore Tor/Tor
#27274closedASan on OSX Travis is incompatible with Rust's santiziersCore Tor/Tor
#27915newMake rust doctests get linked in same way as other rust testsCore Tor/Tor

Change History (78)

comment:1 Changed 11 months ago by teor

Component: - Select a componentCore Tor/Tor
Keywords: rust tor-test added
Milestone: Tor: 0.3.4.x-final
Points: 1
Type: enhancementdefect
Version: Tor: 0.3.2.1-alpha

comment:2 Changed 11 months ago by teor

Hello71 has a branch here: https://cgit.alxu.ca/tor.git/commit/?h=fix-rust-tests

But it needs to inherit libraries and library flags from the Makefile,
And it needs to build Rust with asan, if asan is turned on.

We want to pass the -Z sanitizer flag to Rust: https://github.com/japaric/rust-san

comment:3 Changed 11 months ago by teor

Status: newneeds_revision

comment:4 Changed 11 months ago by Hello71

Status: needs_revisionneeds_review

still doesn't work with --enable-fragile-hardening due to ubsan, might work if that's commented out (or maybe not?)

I still think the best way is to build a "libtor.so" and link all the tests with it, so we don't have to pass all the dependencies in or interrogate the toolchain about how to link sanitizers.

comment:5 Changed 11 months ago by teor

Keywords: 033-backport added
Version: Tor: 0.3.2.1-alphaTor: 0.3.3.1-alpha

Let's get a minimal solution working first, and then look at ubsan and shared libraries.

Is the set of ".a" files minimal?
Or should we use an environmental variable with that set of files instead?
(For example, the set of tor source files linked into src/test/test would be a good place to start.)

comment:6 Changed 11 months ago by nickm

Keywords: review-group-34 added

comment:7 Changed 10 months ago by dgoulet

Reviewer: isis

Reviewer for week 03/19

comment:8 Changed 10 months ago by isis

Hello Hello71! (hah) Thanks a whole bunch for looking into this and for the patches! This looks much better than the attempts I was making going through cargo and rust #[cfg] linker directives.

Some notes on a couple issues:

  1. I reverted 350f76d3 and 8748ddac in my bug25386 branch, as they both affected the TravisCI builds to enable OSX (which takes forever, hence why it's disabled by default) and also to (mostly?) disable clang (not sure why this was done? We like testing our C with different compilers, and clang's LeakSanitizer has caught leaks where GCC has not). Generally, in your personal repo, if you'd like to enable OSX builds for a branch, the way to do so is to make another branch off of it with the commits to enable the OSX builds, so that they don't accidentally get merged and make everyone's builds suddenly slow. (Also the changes seem to have resulted in building with GCC and --enable-cargo-online-mode twice somehow?)
  1. Nick's make test-rust target from #25071 has been broken, due to no longer finding the test_rust.sh script.
  1. make check fails. (That Travis build is just a copy of your branch that I prefixed with testing/hello71/ to keep it out of my branch namespace.) It looks like it's pretty angry about missing symbols. Locally, on my machine, building out-of-tree, it's mad about:
    FAIL: src/test/test_rust.sh
    ===========================
    
    error: could not find `Cargo.toml` in `/home/isis/code/torproject/tor-build/src/rust` or any parent directory`
    

(My tor/ directory is at /home/isis/code/torproject/tor.) This will break our Jenkins builds.

I think once we're able to get these things fixed, then we can start on the UBSan/other sanitiser issues (possibly merging in-between).

Last edited 10 months ago by isis (previous) (diff)

comment:9 in reply to:  8 ; Changed 10 months ago by isis

Replying to isis:

Hello Hello71! (hah) Thanks a whole bunch for looking into this and for the patches! This looks much better than the attempts I was making going through cargo and rust #[cfg] linker directives.

Some notes on a couple issues:

  1. I reverted 350f76d3 and 8748ddac in my bug25386 branch, as they both affected the TravisCI builds to enable OSX (which takes forever, hence why it's disabled by default) and also to (mostly?) disable clang (not sure why this was done? We like testing our C with different compilers, and clang's LeakSanitizer has caught leaks where GCC has not). Generally, in your personal repo, if you'd like to enable OSX builds for a branch, the way to do so is to make another branch off of it with the commits to enable the OSX builds, so that they don't accidentally get merged and make everyone's builds suddenly slow. (Also the changes seem to have resulted in building with GCC and --enable-cargo-online-mode twice somehow?)
  1. Nick's make test-rust target from #25071 has been broken, due to no longer finding the test_rust.sh script.
  1. make check fails. (That Travis build is just a copy of your branch that I prefixed with testing/hello71/ to keep it out of my branch namespace.) It looks like it's pretty angry about missing symbols. Locally, on my machine, building out-of-tree, it's mad about:
    FAIL: src/test/test_rust.sh
    ===========================
    
    error: could not find `Cargo.toml` in `/home/isis/code/torproject/tor-build/src/rust` or any parent directory`
    

(My tor/ directory is at /home/isis/code/torproject/tor.) This will break our Jenkins builds.

I think once we're able to get these things fixed, then we can start on the UBSan/other sanitiser issues (possibly merging in-between).


Oh, one more note:

  1. This approach seems pretty sane, but one thing it won't allow is doing:
    cd src/rust/protover
    cargo test
    

and getting a positive result. I'm not sure how much we should care about that, especially if—as a team—we're going to eventually agree that things will simply be rewritten in Rust, as opposed to maintained in both languages. (I.e. it's only a problem while we maintain both, and maintain the FFI boundary for both.)

comment:10 in reply to:  9 Changed 10 months ago by Hello71

Replying to isis:

  1. I reverted 350f76d3 and 8748ddac in my bug25386 branch, as they both affected the TravisCI builds to enable OSX (which takes forever, hence why it's disabled by default) and also to (mostly?) disable clang (not sure why this was done? We like testing our C with different compilers, and clang's LeakSanitizer has caught leaks where GCC has not). Generally, in your personal repo, if you'd like to enable OSX builds for a branch, the way to do so is to make another branch off of it with the commits to enable the OSX builds, so that they don't accidentally get merged and make everyone's builds suddenly slow. (Also the changes seem to have resulted in building with GCC and --enable-cargo-online-mode twice somehow?)

This is why I don't like Travis's method of putting the configuration inside the repository. Here, I specifically want the changes to only apply to this branch. I suppose I could move that to another branch, and base this one on that one, but that sounds like a huge pain.

  1. Nick's make test-rust target from #25071 has been broken, due to no longer finding the test_rust.sh script.

I will investigate.

  1. make check fails. (That Travis build is just a copy of your branch that I prefixed with testing/hello71/ to keep it out of my branch namespace.) It looks like it's pretty angry about missing symbols.

Yes, I am aware, it doesn't work right with sanitizers. I discussed that with teor to some extent, but as I recall, I said "we should make a 'libtor.so'", he said "no, that will cause more problems", and I thought "I don't see any better way of doing it. I'll come back to it later." and then forgot to come back to it. I think there might be a solution in rustc -Csomething-or-other though.

Locally, on my machine, building out-of-tree, it's mad about:

FAIL: src/test/test_rust.sh
===========================

error: could not find `Cargo.toml` in `/home/isis/code/torproject/tor-build/src/rust` or any parent directory`

(My tor/ directory is at /home/isis/code/torproject/tor.) This will break our Jenkins builds.

I think once we're able to get these things fixed, then we can start on the UBSan/other sanitiser issues (possibly merging in-between).

Ah, quite possible, I did not test this. I will investigate.

Replying to isis:

Oh, one more note:

  1. This approach seems pretty sane, but one thing it won't allow is doing:
    cd src/rust/protover
    cargo test
    

and getting a positive result. I'm not sure how much we should care about that, especially if—as a team—we're going to eventually agree that things will simply be rewritten in Rust, as opposed to maintained in both languages. (I.e. it's only a problem while we maintain both, and maintain the FFI boundary for both.)

This seems easy to rectify, just make test_rust.sh take a crate to test, or potentially check the current directory or something. In theory, we could do it in cargo too, but I don't know how to add libraries only during testing (or if such a thing exists).

comment:11 Changed 10 months ago by Hello71

Owner: set to Hello71
Status: needs_reviewassigned

comment:12 Changed 10 months ago by Hello71

Status: assignedneeds_revision

comment:13 Changed 10 months ago by isis

Points: 13
Sponsor: Sponsor8-can

comment:14 Changed 10 months ago by chelseakomlo

Cc: chelseakomlo added

comment:15 Changed 10 months ago by chelseakomlo

Hi, apologies for the late review, but is there a reason why the #3 option in the description is for doctests only? Ideally, we would want linking for at minimum integration tests, ideally all levels of tests.

comment:16 in reply to:  15 Changed 10 months ago by Hello71

Replying to chelseakomlo:

Hi, apologies for the late review, but is there a reason why the #3 option in the description is for doctests only? Ideally, we would want linking for at minimum integration tests, ideally all levels of tests.

er, I meant all tests. everything that gets run by cargo test.

comment:17 Changed 10 months ago by chelseakomlo

Cool, thanks for clarifying and for working on this.

Another necessary criteria to think about for this effort is being able to run individual tests, or tests at a module level to ensure a quick feedback loop.

comment:18 Changed 10 months ago by Hello71

Status: needs_revisionneeds_review
Version: Tor: 0.3.3.1-alphaTor: 0.3.3.2-alpha

Fixed all problems except sanitizers not working. Asked #rust-beginners about building it using cargo, concluded it's too much work, and besides, scripts/cargo_test doesn't seem that much harder than cargo test. It would be nice to not duplicate the list of libraries, but I think that's a discussion for another time. this seems Good Enough for now.

comment:19 Changed 10 months ago by Hello71

I dunno how I changed the version, if it was automatic or maybe I scrolled there by accident. Change it back if it's important.

Commits are in chronological order for benefit of reviewers, I will rebase if approved. https://cgit.alxu.ca/tor.git/diff/?id2=master&id=fix-rust-tests for overview

comment:20 Changed 10 months ago by isis

Version: Tor: 0.3.3.2-alphaTor: 0.3.3.1-alpha

comment:21 Changed 10 months ago by isis

Status: needs_reviewmerge_ready

Hi, this looks great! Thanks!

Just one tiny thing: when you squash, please remove commit f7b714ba411eb7ccdfcafe676df28f81bb823b57, as it breaks out-of-directory builds. (It should be $abs_top_srcdir in that line, since the test_rust.sh script doesn't get copied to the build dir.)

I added a commit on top in my bug25386_v2 branch, which changed the test you added to actually check the functionality of protover::compute_for_old_tor, and found a bug (#25605), so this is pretty cool.

I recommend merging whenever Hello71 squashes, and then I'll put the tests I made/changed in #25605.

Last edited 10 months ago by isis (previous) (diff)

comment:22 Changed 10 months ago by isis

Oh, also this needs a changes file. I can add that, if you like.

comment:23 Changed 10 months ago by Hello71

Status: merge_readyneeds_review

squashed and rebased on master (addition of --all-features flag). I only applied it in test_rust.sh; do you think it should be applied in cargo_test script instead? I think probably not, since I was trying to make cargo_test do basically the same thing as cargo test.

setting needs_review for that and a quick sanity check that I didn't break anything while squashing. no major changes in the overall diff though.

comment:24 Changed 10 months ago by Hello71

rebased on master, added changes file

comment:25 Changed 10 months ago by Hello71

probably fixed non-system libraries

comment:26 Changed 10 months ago by isis

Oh, it also looks like your branch before squashing was failing when compiled with ASan? https://travis-ci.org/isislovecruft/tor/builds/357186429

Locally I was configuring with --enable-rust --enable-cargo-online-mode --enable-fatal-warnings, and forgot to use --enable-expensive-hardening.

Will check out the new branch and test that now.

comment:27 in reply to:  26 Changed 10 months ago by isis

Replying to isis:

Oh, it also looks like your branch before squashing was failing when compiled with ASan? https://travis-ci.org/isislovecruft/tor/builds/357186429

Locally I was configuring with --enable-rust --enable-cargo-online-mode --enable-fatal-warnings, and forgot to use --enable-expensive-hardening.

Will check out the new branch and test that now.


Okay, ASan is still failing here, and we discussed potential solutions in IRC a bit:

  1. Additionally build a libtor.so (and libtool-ise it?) and link it in when compiling with cargo test.
  2. Keep the original way that we're currently doing things in src/rust/test_rust.sh, but also add Hello71's branch here with a configure flag --enable-testing-c-from-rust (which sets --disable-expensive-hardening) and then we add a row/build to the CI build matrixes for additionally running that. (Potentially removing one of the cargo offline builds, since having two is a little overly-redundant… but that's a separate issue to this one.)
  3. Other not-as-good ideas were discussed.

Any other ideas? Which of these sounds like a saner way forward?

comment:28 Changed 10 months ago by isis

Status: needs_reviewneeds_revision

comment:29 Changed 10 months ago by Hello71

I think I agree that libtool is too much work. Possibly we could revisit that if we move to a better build system at some point.

I think I'll try my wrapper linker solution again and see how it works. If that doesn't work out, I'll do the solution where we do CI builds "no rust, ubsan + asan", "rust, asan only".

There is another problem though. The Rust code is not really well segmented into crates right now; it is possible for one crate to call indirectly code in another crate, through the magic of static linking. However, this does not work in tests, because there we only use Rust code from a single crate. Simply adding libtor_rust.a does not work, since then we get multiple definition errors. Presently, this is not an issue, because the linker automagically optimizes everything out with --gc-sections --as-needed. For some reason though, adding asan confuses the linker, and trying to test anything but protover causes undefined references to protover functions (because the C version is not compiled if Rust is enabled, but if we are testing Rust then we only add the current Rust crate). Moreover, eventually it is likely that we will want real interdependencies between crates, and I think there is little to no value to juggle Rust dependencies when there are no even hypothetical plans to embed them in something other than Tor proper all together. I think the best solution is to just merge all our Rust crates together, and I've filed #25639 to that effect. There may be better solutions, and I'm open to suggestions, but it seems to me like that is the only practical one.

comment:30 in reply to:  29 Changed 10 months ago by chelseakomlo

Replying to Hello71:

I think I agree that libtool is too much work. Possibly we could revisit that if we move to a better build system at some point.

I think I'll try my wrapper linker solution again and see how it works. If that doesn't work out, I'll do the solution where we do CI builds "no rust, ubsan + asan", "rust, asan only".

Moreover, eventually it is likely that we will want real interdependencies between crates, and I think there is little to no value to juggle Rust dependencies when there are no even hypothetical plans to embed them in something other than Tor proper all together. I think the best solution is to just merge all our Rust crates together, and I've filed #25639 to that effect. There may be better solutions, and I'm open to suggestions, but it seems to me like that is the only practical one.

This isn't actually true. For example, we are currently in discussion about modularizing tor such that we can have multiple builds (i.e, for mobile clients, hidden services, etc). Being able to include/not include crates in select builds will be valuable for this effort. Furthermore, external projects will be able to leverage this as well, in a way that is not currently possible with tor's C code.

Moving all code into a single crate is a non-starter for me, as this goes against the larger effort of having tor be more modular in the future.

I would recommend looking at other Rust/C projects such as Gecko, talking to some Mozilla people, and thinking through something that both allows this functionality as well as enables us to have a clean/modular project structure into the future.

Last edited 10 months ago by chelseakomlo (previous) (diff)

comment:31 Changed 10 months ago by nickm

Keywords: 034-triage-20180328 added

comment:32 Changed 10 months ago by nickm

Keywords: 034-removed-20180328 added

Per our triage process, these tickets are pending removal from 0.3.4.

comment:33 Changed 10 months ago by nickm

Keywords: 034-included-20180401 added; 034-removed-20180328 removed
Sponsor: Sponsor8-canSponsorQ

Doing something here will be needed to make progress with our rust code, which is needed for privcount.

comment:34 Changed 10 months ago by chelseakomlo

Cc: manishearth@… added

comment:35 Changed 9 months ago by Hello71

so it looks like building the shared library is actually the right way to go. asan applies only to the shared library in this case, can probably use -Z sanitizer=address on nightly for rust tests. everything actually works though, no inscrutable multiple definition errors. few hitches:

  1. libtool sucks. currently using meson. would rather we switch to that entirely, but not opposed to someone else figuring out how to make libtor.so (basically tor minus tor_main.c) using libtool instead
  1. still figuring out how best to link it in; hopefully will not use RUSTFLAGS so we don't have to recompile all dependencies on each test
Last edited 9 months ago by Hello71 (previous) (diff)

comment:36 Changed 9 months ago by Hello71

I have pushed to https://cgit.alxu.ca/tor.git/log/?h=meson an implementation of the shared library approach (along with a bunch of other crap that I'll have to separate out). This approach seems to be the most reliable and, with -static-libasan, hopefully fixes all issues with asan incompatibilities. remaining problems:

  1. still need to actually build a shared library, so either #23846 or switch to a better build system.
  1. rustdoc doesn't take -Z sanitizer (https://github.com/rust-lang/rust/issues/43031), but I think maybe we can hack around that by cleaning first and just accept that doctests won't have sanitizers for now.

comment:37 Changed 9 months ago by Hello71

latest iteration:

  1. still need to build a shared library
  1. still needs cleanup, i.e. splitting commits. current state of code LGTM, good if people want to review Tor on meson vs autotools :)
  1. needs testing on Mac and Windows (Rust should work on Windows now!)
  1. cargo testing a single directory is once again unsupported. should be possible without *too* much work, but I need to think of a good interface. I think this is not a huge issue though, since cargo doesn't rebuild everything anymore. Definitely shouldn't block this bug, anyways.
  1. everything works except rustdoc with asan due to aforementioned Rust bug. even Rust is built with asan, so it should catch everything asan can catch (within Rust limits, e.g. libstd is not instrumented). filed #25841 for actually checking that this works.

the basic architecture of this solution is fairly simple, and I tried to make minimal changes to the existing crate layout. it's basically 1. build a shared library, 2. get Rust to link with that shared library at compile-time, 3. use LD_LIBRARY_PATH so it can find it at run-time. the rest is finicky stuff to deal with Rust bugs like https://github.com/rust-lang/rust/issues/41807.

"minimal changes" means build scripts instead of links key in manifest. the latter might be preferable since it means the build scripts don't need to know anything about where they're being built. however, because links keys may not be duplicated in a dependency tree, that requires all Rust -> C definitions to be in a single crate, which is better handled in #25639.

comment:38 Changed 9 months ago by Hello71

It has occurred to me that shared libraries also split the global variable namespace along with the function namespace. This may be a problem.

comment:39 Changed 9 months ago by Hello71

I give up. Manish, what should we do here?

comment:40 in reply to:  39 Changed 8 months ago by chelseakomlo

Replying to Hello71:

I give up. Manish, what should we do here?

Do you mind clarifying the outstanding blockers for this ticket? It is a bit hard to follow what has been resolved/is still outstanding (if the "latest iteration" comment is still valid, but there are recently-discovered blockers to closing this issue, more clarify on those blockers would be helpful).

comment:41 Changed 8 months ago by Hello71

so I realised that teor was right, you can't just have half of your program in a shared library. I think I was getting weird errors due to mixing gcc and llvm asan (different versions). I will try again hopefully this week with a shared library.

comment:42 Changed 8 months ago by manish.earth

Sorry, yeah, I'm not very clear on what you need from me here.

(Apologies for not responding earlier, I was super busy and then completely forgot. Feel free to bug me here or on twitter if that happens again)

comment:43 Changed 8 months ago by nickm

Hello71, or anybody: can you summarize what the actual problem is at this point? Chelseakomlo, Manish, and I are all confused about where we are.

It looks like the goal of this ticket is to make it so Tor's C code is linked with the Rust tests, so that Rust tests can call functions that invoke C functions. And it looks like we're running into linking issues. But, what are they? And what are we trying?

comment:44 Changed 8 months ago by chelseakomlo

Summary: fix rust testsLink Rust Tests to C Dependencies in Tor (allow integration testing from Rust to C)

comment:45 Changed 8 months ago by nickm

To summarize, I think the issues here (as I understand them) are these. I'll try to isolate them better and in more detail over the course of the week, but for now I'm just writing them down so I won't forget.

  1. When we invoke cargo test, we need to make sure that RUSTFLAGS includes the -L and -l flags necessary to link our C code, including system libraries. We can do that in lots of different ways.
  1. But doing this doesn't seem to actually pass the necessary flags to the linker when rustdoc is run. That's one problem. I think there have been a few bugs of this kind in the past, like https://github.com/rust-lang/cargo/issues/1401 .
  1. Remaining problem is that when we have compiled our C code using -fsanitize=address and -fsanitize=undefined, we get linker issues. Adding these options to the linker line doesn't seem to help. Possibly we need to explicitly link with the backend files here, or somehow stop rustc from telling the linker -nodefaultlibs?

comment:46 Changed 8 months ago by manish.earth

Okay, so (2) is specifically a problem with doctests only? Regular cargo test works fine?

Or is (3) a problem for regular cargo test as well?

comment:47 Changed 8 months ago by Hello71

My plan was originally to work on this instead of writing down the problems, but apparently I really don't want to work on it, so I'll write them down as I see them. This obsoletes most if not all of what I said above.

If we want to use cargo test to test things, then the following must be resolved:

  1. Cargo needs to learn to link C Tor libraries in when running Rust tests. It's fine if the solution to this problem actually links C Tor libraries always instead of only during tests, because static libraries do not carry dependency information on any modern platform. (I believe not even Windows, but correct me if I'm wrong.) This can be accomplished a few ways:
  1. set RUSTFLAGS and RUSTDOCFLAGS to "-L... -L... -L... -l... -l..." etc, either always or only when testing. the downside of this option is that it also links C Tor libraries when compiling Rust Tor dependencies, which sounds bad (but I suspect is actually fine if everything is linked together in "big bag of parts" manner at the end). always is better because cargo will save the value of these variables and recompile *all Rust code* (due to the previous problem). this isn't a huge issue now, but if we add a bunch of dependencies (like winapi, ugh) that could be an issue later.
  1. do the same thing but specify rustflags in cargo configuration
  1. use one or more build scripts that output all C Tor libraries as cargo:rustc-link-lib lines (make sure you add cargo:rustc-link-search too obviously). it is possible that using one in external only will work. I suspect we should rename and split external into tor_c and tor_c-sys, where the latter uses bindgen or manual curation for pure bindings only, and the former does high-level wrappers, but that can probably be done separately. I believe this is supposed to automatically work for rustdoc too.
  1. use "links" key and provide the libraries in cargo configuration. this is possibly less preferable because it forecloses other uses of build scripts, like bindgen.

I am in favor of method c. It is possible that *none* of these work, however. This might be the case if Rust calls into C which calls back into the crate we are currently testing. If so, then a complicated build script might be necessary that excludes the current crate from the RUSTFLAGS. Additionally, note that "make a shared library" does *not* work, because then there will be multiple copies of global data structures.

  1. sanitizers: if rustc is used to link tests (mandatory if using cargo test), then one of the following must be done (otherwise you will get "undefined reference" errors because the C code is looking for sanitizer symbols):
  1. interpose the linker with -C linker to add -fsanitize options. I suspect -C link-arg won't work because of the weird order dependency of linker arguments. I also suspect that this will not work properly, especially if we want Rust tests to be run with sanitizers enabled.
  1. pass -Z sanitizer options to Rust, either via exporting RUSTFLAGS or setting build.rustflags in cargo config. this requires that the Rust sanitizers are of a compatible version with the C sanitizers, otherwise there will be very strange errors, mostly multiple definition errors of __asan_* functions. usually, using clang to build C code is both necessary and sufficient. presently, gcc 8 should work with rustc 1.26, but probably not with newer Rust versions (gcc tends to trail behind on sanitizer versions).
  1. a method should be devised if possible to test only one crate at a time. komlo asked for this somewhere above. probably a wrapper script is the best solution, but I'm not sure about the details. for example, should running it from the build directory be necessary? does it need to be autoconf generated, or can it be static?
Last edited 8 months ago by Hello71 (previous) (diff)

comment:48 Changed 8 months ago by isis

Milestone: Tor: 0.3.4.x-finalTor: 0.3.5.x-final

Triaging some tickets not absolutely vital to 0.3.4 release to 0.3.5. These are fine to do in 0.3.4, but they aren't a must.

comment:49 in reply to:  46 Changed 8 months ago by nickm

Replying to manish.earth:

Okay, so (2) is specifically a problem with doctests only? Regular cargo test works fine?

That's right, I believe.

Or is (3) a problem for regular cargo test as well?

I think (3) is a problem for all the tests.

comment:50 Changed 8 months ago by manish.earth

I'm not really sure what to do for sanitizer, but Hello71's option (c) "use one or more build scripts that output all C Tor libraries as cargo:rustc-link-lib" seems like the right way to go for the other stuff.

Or we could add support for -L in rustdoc, shouldn't be hard.

comment:51 Changed 8 months ago by Hello71

Status: needs_revisionnew

for sanitizers, whoever works on it, it may or may not help to pass gcc -static-libasan -static-libubsan. try that if you have issues.

I'm too frustrated dealing with this, so someone else can deal with it :)

comment:52 Changed 7 months ago by chelseakomlo

Owner: Hello71 deleted
Status: newassigned

comment:53 Changed 7 months ago by nickm

Owner: set to nickm

comment:54 Changed 7 months ago by nickm

Milestone: Tor: 0.3.5.x-finalTor: 0.3.4.x-final

comment:55 Changed 7 months ago by Hello71

oh, there's also 1. e. give up and write all the tests in C. should still fix sanitizers, but that way that can be put off until later.

comment:56 Changed 7 months ago by isis

I think I'm also in favour of going with Hello71's option 1C. For the sanitiser stuff, 2B is probably a better choice and probably we should have some configure.ac checks that we're either building the C with clang or else have a new enough GCC. I have no opinion on the "run a single crate's tests" thing—which should probably be a separate issue—other than, yes, we should do that, and in this ticket we should make sure that we don't do anything that will make doing that more difficult.

comment:57 Changed 7 months ago by nickm

Okay. I have the start of a build script in a branch called rust_build_script_v1.

Probably not ready for merge yet, but it solved the linking issue for me on my desktop.

comment:58 Changed 7 months ago by nickm

I have a possibly better variation of the idea above in rust_build_script_v2.

comment:59 Changed 7 months ago by nickm

Status: assignedneeds_review

I have a variation in rust_build_script_v3: It's better documented, and it has the tricks necessary to get the sanitizers to work (for me) with clang and gcc.

I was hoping not to need the "linker script" trick, but with clang, it turns out to be hard to actually specify "-lclangrt.asan" in a way that clang will accept. I think you might need to list the architecture as part of the library's name for that -- so just specifying "static-libasan" was indeed easier. But to pass that to the linker correctly, it needs to go near the start of the link line, and for that, we need to have a shell script.

I think we might be needlessly rebuilding our rust modules when we run the tests here, because the RUSTFLAGS option is only set when testing. I didn't see a way to set RUSTFLAGS from build.rs, but that would be a better way around this.

Note that the tests don't _pass_ yet, but I think that's another ticket.

comment:61 Changed 7 months ago by nickm

My branch additional_rust_test_fixes is sufficient to make the tests pass for me.

I had to disable the doctests, since they don't seem to handle linker arguments.

comment:62 Changed 7 months ago by nickm

I've added more to additional_rust_test_fixes to get it "almost" working on Travis. More insight may be needed.

I've also merged catalyst's "allow_fail_rust" branch to 0.3.4 and 0.3.5 so that travis won't complain so loudly for now.

I'd still like review on additional_rust_test_fixes, with a plan to merging it in 0.3.4. I'm also hoping that until we can get the underlying linking issues fixes, we can have some rust builders that don't enable fragile-hardening, so that we can at least get some visibility into the rust tests, and not break them again.

comment:63 in reply to:  60 Changed 7 months ago by isis

Status: needs_reviewmerge_ready

Replying to nickm:

https://github.com/torproject/tor/pull/159 is the PR


Looks good to me, modulo a couple of Hello71's comments about allowing spaces in paths. It's still not quite working on Travis and it's failing a bit differently for me locally, but this does get rid of the linker issues so we can probably iterate on this from here on.

Replying to nickm:

I've added more to additional_rust_test_fixes to get it "almost" working on Travis. More insight may be needed.

I've also merged catalyst's "allow_fail_rust" branch to 0.3.4 and 0.3.5 so that travis won't complain so loudly for now.

Good call.

I'd still like review on additional_rust_test_fixes, with a plan to merging it in 0.3.4. I'm also hoping that until we can get the underlying linking issues fixes, we can have some rust builders that don't enable fragile-hardening, so that we can at least get some visibility into the rust tests, and not break them again.

The additional fixes also look good to me. I'll mess around this afternoon with chasing down some of the remaining errors.

For the doctests, should we just have a policy of "if you call C and also have doctests for your code, then you have to put ignore on the doctests or otherwise disable them"?

comment:64 Changed 7 months ago by nickm

Merged "additional_rust_fixes" to 0.3.4 and forward.

For the doctests, should we just have a policy of "if you call C and also have doctests for your code, then you have to put ignore on the doctests or otherwise disable them"?

I think that's the best we can do, until rustdoc starts passing the right options to rustc. (Perhaps it is doing so already, and my desktop rust is just too old.)

comment:65 Changed 7 months ago by nickm

Status: merge_readyaccepted

comment:66 Changed 7 months ago by chelseakomlo

Just as a side note- it might be worth opening a bug against rustdoc/giving rust people a heads up about this issue (if we haven't already).

comment:67 in reply to:  64 ; Changed 7 months ago by Hello71

Replying to nickm:

Merged "additional_rust_fixes" to 0.3.4 and forward.

For the doctests, should we just have a policy of "if you call C and also have doctests for your code, then you have to put ignore on the doctests or otherwise disable them"?

I think that's the best we can do, until rustdoc starts passing the right options to rustc. (Perhaps it is doing so already, and my desktop rust is just too old.)

I guess you missed it on IRC, rustdoc already accepts -C on nightly: https://github.com/rust-lang/rust/pull/49956. I assume this will be in 1.27, to be released today.

comment:68 in reply to:  66 Changed 7 months ago by nickm

Replying to chelseakomlo:

Just as a side note- it might be worth opening a bug against rustdoc/giving rust people a heads up about this issue (if we haven't already).

I think this is right -- I want to do this once I've closed this and opened new tickets for the remaining issues.

comment:69 in reply to:  67 ; Changed 7 months ago by nickm

Replying to Hello71:

Replying to nickm:

Merged "additional_rust_fixes" to 0.3.4 and forward.

For the doctests, should we just have a policy of "if you call C and also have doctests for your code, then you have to put ignore on the doctests or otherwise disable them"?

I think that's the best we can do, until rustdoc starts passing the right options to rustc. (Perhaps it is doing so already, and my desktop rust is just too old.)

I guess you missed it on IRC, rustdoc already accepts -C on nightly: https://github.com/rust-lang/rust/pull/49956. I assume this will be in 1.27, to be released today.

Okay; we'd have either wait a while to use this, until we can rely on folks having this. (Alternatively, we could make it optional.)

comment:70 in reply to:  69 Changed 7 months ago by teor

Replying to nickm:

Replying to Hello71:

Replying to nickm:

Merged "additional_rust_fixes" to 0.3.4 and forward.

For the doctests, should we just have a policy of "if you call C and also have doctests for your code, then you have to put ignore on the doctests or otherwise disable them"?

I think that's the best we can do, until rustdoc starts passing the right options to rustc. (Perhaps it is doing so already, and my desktop rust is just too old.)

I guess you missed it on IRC, rustdoc already accepts -C on nightly: https://github.com/rust-lang/rust/pull/49956. I assume this will be in 1.27, to be released today.

Okay; we'd have either wait a while to use this, until we can rely on folks having this. (Alternatively, we could make it optional.)

Can we make it optional?

I wrote extensive rustdoc tests for the PrivCount random double code. I was using OSRng as a workaround until #24660, but I'd like to use our wrapped Rng instead.

comment:71 Changed 7 months ago by nickm

Can we make it optional?

Sure -- but someone will need to come up with a mechanism that works and doesn't cause too much pain.

comment:72 Changed 7 months ago by nickm

Milestone: Tor: 0.3.4.x-finalTor: 0.3.5.x-final

I am thinking that our existing 0.3.4 solutions are as good as they are likely to get, though I won't rule out a backport of something elegant.

comment:73 in reply to:  71 ; Changed 7 months ago by isis

Replying to nickm:

Can we make it optional?

Sure -- but someone will need to come up with a mechanism that works and doesn't cause too much pain.


So 1.27 is now the stable rust, and it does include the -C option for rustdoc.

I'm not exactly understanding which part is supposed to be optional? Is it:

  1. Passing the same flags as we pass to RUSTFLAGS to the rustdoc -C should be optional?
  2. Or, compiling tests which expect to use C code should be optional? (If so, see #26398.)
  3. Or something else?

comment:74 in reply to:  73 ; Changed 7 months ago by teor

Replying to isis:

Replying to nickm:

Can we make it optional?

Sure -- but someone will need to come up with a mechanism that works and doesn't cause too much pain.


So 1.27 is now the stable rust, and it does include the -C option for rustdoc.

I'm not exactly understanding which part is supposed to be optional? Is it:

  1. Passing the same flags as we pass to RUSTFLAGS to the rustdoc -C should be optional?

Yes, we need to be able to:

  • pass -C when rustdoc supports it (should we do an autoconf test?)
  • not pass -C when rustdoc doesn't support it

I don't know if we need to be able to:

  • disable -C even if rustdoc supports it - do we need to check that we can compile without -C?
  1. Or, compiling tests which expect to use C code should be optional? (If so, see #26398.)

Yes, we need to be able to:

  • disable rustdoc tests which use C code when rustdoc doesn't support -C

I don't know if we need to be able to:

  • disable all rust tests that use C code - do we need to make tests faster, or check we can compile rust-only?
  1. Or something else?

comment:75 Changed 6 months ago by nickm

Keywords: 035-removed-20180711 added
Milestone: Tor: 0.3.5.x-finalTor: unspecified

These tickets are being triaged out of 0.3.5. The ones marked "035-roadmap-proposed" may return.

comment:76 Changed 5 months ago by catalyst

I'm making a quick note here because it might be a while before I can do an up-to-date replication recipe. --enable-fragile-hardening still results in link errors.

This failed for me on Xenial amd64 with the OS Rust packages installed. I haven't built the failing configuration for a while, but see below.

This also seems to still fail on Travis, e.g.,

error: linking with `/home/travis/build/torproject/tor/link_rust.sh` failed: exit code: 1
  |
  = note: "/home/travis/build/torproject/tor/link_rust.sh" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/home/travis/build/torproject/tor/src/rust/target/debug/deps/crypto-ace3d04d5d6c7104.1y16o1qfye96o7m0.rcgu.o" "/home/travis/build/torproject/tor/src/rust/target/debug/deps/crypto-ace3d04d5d6c7104.3rngp6bm2u2q5z0y.rcgu.o" "/home/travis/build/torproject/tor/src/rust/target/debug/deps/crypto-ace3d04d5d6c7104.4mjvrpa5so4so4jc.rcgu.o" "/home/travis/build/torproject/tor/src/rust/target/debug/deps/crypto-ace3d04d5d6c7104.4oc10dk278mpk1vy.rcgu.o" "/home/travis/build/torproject/tor/src/rust/target/debug/deps/crypto-ace3d04d5d6c7104.oa3rad818d8sgn4.rcgu.o" "-o" "/home/travis/build/torproject/tor/src/rust/target/debug/deps/crypto-ace3d04d5d6c7104" "/home/travis/build/torproject/tor/src/rust/target/debug/deps/crypto-ace3d04d5d6c7104.crate.allocator.rcgu.o" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs" "-L" "/home/travis/build/torproject/tor/src/rust/target/debug/deps" "-L" "/home/travis/build/torproject/tor/src/lib" "-L" "/home/travis/build/torproject/tor/src/ext/keccak-tiny" "-L" "/home/travis/build/torproject/tor/src/ext/ed25519/ref10" "-L" "/home/travis/build/torproject/tor/src/ext/ed25519/donna" "-L" "/home/travis/build/torproject/tor/src/trunnel" "-L" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "-Wl,--whole-archive" "-l" "tor-crypt-ops-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-sandbox-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-encoding-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-fs-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-time-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-net-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-thread-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-memarea-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-log-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-lock-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-fdio-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-container-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-smartlist-core-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-string-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-malloc" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-wallclock" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-err-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-intmath-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-ctime-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "curve25519_donna" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "keccak-tiny" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "ed25519_ref10" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "ed25519_donna" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "or-trunnel-testing" "-Wl,--no-whole-archive" "-Wl,-Bdynamic" "-l" "z" "-l" "m" "-l" "ssl" "-l" "crypto" "-l" "event" "-l" "lzma" "-l" "scrypt" "-l" "seccomp" "-l" "cap" "-l" "pthread" "-l" "dl" "-Wl,-Bstatic" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libtest-b66ae0f7ceefd4a4.rlib" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libterm-d827f4b0e7afdcf0.rlib" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libgetopts-beedc388f272415a.rlib" "/home/travis/build/torproject/tor/src/rust/target/debug/deps/libexternal-b51270571fdbe9aa.rlib" "/home/travis/build/torproject/tor/src/rust/target/debug/deps/libsmartlist-bef593dabcf59f69.rlib" "/home/travis/build/torproject/tor/src/rust/target/debug/deps/librand-dcbd058a5a82c6a4.rlib" "/home/travis/build/torproject/tor/src/rust/target/debug/deps/librand_core-ffccd4631e4e00cb.rlib" "/home/travis/build/torproject/tor/src/rust/target/debug/deps/liblibc-212792d827b59ce3.rlib" "/home/travis/build/torproject/tor/src/rust/target/debug/deps/libdigest-7a6c0b2ac402fc2f.rlib" "/home/travis/build/torproject/tor/src/rust/target/debug/deps/libgeneric_array-433158e47fbb9822.rlib" "/home/travis/build/torproject/tor/src/rust/target/debug/deps/libtypenum-4ef63ac97eea58b4.rlib" "-Wl,--start-group" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-0cce0e0e34e933aa.rlib" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-7bed87070cafeede.rlib" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-e76963fdf0c94daa.rlib" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-8cd3b0417a81fb26.rlib" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_system-387bd949d1b36a91.rlib" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-453d825a151d7dec.rlib" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-5235bf36189564a3.rlib" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-5725e7f9b84bd931.rlib" "-Wl,--end-group" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-874d313336916306.rlib" "-Wl,-Bdynamic" "-l" "util" "-l" "util" "-l" "dl" "-l" "rt" "-l" "pthread" "-l" "pthread" "-l" "gcc_s" "-l" "c" "-l" "m" "-l" "rt" "-l" "pthread" "-l" "util" "-l" "util"
  = note: /home/travis/build/torproject/tor/src/lib/libtor-crypt-ops-testing.a(src_lib_libtor_crypt_ops_testing_a-crypto_rand.o): In function `crypto_strongest_rand_raw':
          /home/travis/build/torproject/tor/src/lib/crypt_ops/crypto_rand.c:276: undefined reference to `__asan_handle_no_return'

Full log in https://api.travis-ci.org/v3/job/413659207/log.txt

Note: Travis is still on Trusty last I checked.

comment:77 in reply to:  74 Changed 5 months ago by Hello71

Replying to teor:

Replying to isis:

Replying to nickm:

Can we make it optional?

Sure -- but someone will need to come up with a mechanism that works and doesn't cause too much pain.


So 1.27 is now the stable rust, and it does include the -C option for rustdoc.

I'm not exactly understanding which part is supposed to be optional? Is it:

  1. Passing the same flags as we pass to RUSTFLAGS to the rustdoc -C should be optional?

Yes, we need to be able to:

  • pass -C when rustdoc supports it (should we do an autoconf test?)
  • not pass -C when rustdoc doesn't support it

I don't know if we need to be able to:

  • disable -C even if rustdoc supports it - do we need to check that we can compile without -C?
  1. Or, compiling tests which expect to use C code should be optional? (If so, see #26398.)

Yes, we need to be able to:

  • disable rustdoc tests which use C code when rustdoc doesn't support -C

I don't know if we need to be able to:

  • disable all rust tests that use C code - do we need to make tests faster, or check we can compile rust-only?
  1. Or something else?

The most accurate method to do this seems to be:

  1. rename "test-c-from-rust" to "use-c-from-doctests".
  2. replace ",no_run" with "\n#![cfg(feature = "use-c-from-doctests")]".
  3. delete "#[cfg(feature = "test-c-from-rust")]" everywhere. (this is supposed to be fixed already)
  4. add a configure test to check if rustdoc supports -C. Probably this involves calling rustdoc -C help and checking the exit status. if so, tell the test script to add -C linker=x to RUSTDOCFLAGS as well as RUSTFLAGS (which it does already), and add --features use-c-from-doctests to the cargo test command line. otherwise, do neither.

This might cause the doctests to all fail. If so, or if this sounds like too much work (which I think), I say scrap it and just use cargo test --lib if rustdoc doesn't take -C. I think that sounds like a reasonable interim solution, since rustdoc will take -C everywhere soon enough.

comment:78 in reply to:  76 Changed 5 months ago by Hello71

Replying to catalyst:

I'm making a quick note here because it might be a while before I can do an up-to-date replication recipe. --enable-fragile-hardening still results in link errors.

This failed for me on Xenial amd64 with the OS Rust packages installed. I haven't built the failing configuration for a while, but see below.

This also seems to still fail on Travis, e.g.,

error: linking with `/home/travis/build/torproject/tor/link_rust.sh` failed: exit code: 1
  |
  = note: "/home/travis/build/torproject/tor/link_rust.sh" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/home/travis/build/torproject/tor/src/rust/target/debug/deps/crypto-ace3d04d5d6c7104.1y16o1qfye96o7m0.rcgu.o" "/home/travis/build/torproject/tor/src/rust/target/debug/deps/crypto-ace3d04d5d6c7104.3rngp6bm2u2q5z0y.rcgu.o" "/home/travis/build/torproject/tor/src/rust/target/debug/deps/crypto-ace3d04d5d6c7104.4mjvrpa5so4so4jc.rcgu.o" "/home/travis/build/torproject/tor/src/rust/target/debug/deps/crypto-ace3d04d5d6c7104.4oc10dk278mpk1vy.rcgu.o" "/home/travis/build/torproject/tor/src/rust/target/debug/deps/crypto-ace3d04d5d6c7104.oa3rad818d8sgn4.rcgu.o" "-o" "/home/travis/build/torproject/tor/src/rust/target/debug/deps/crypto-ace3d04d5d6c7104" "/home/travis/build/torproject/tor/src/rust/target/debug/deps/crypto-ace3d04d5d6c7104.crate.allocator.rcgu.o" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs" "-L" "/home/travis/build/torproject/tor/src/rust/target/debug/deps" "-L" "/home/travis/build/torproject/tor/src/lib" "-L" "/home/travis/build/torproject/tor/src/ext/keccak-tiny" "-L" "/home/travis/build/torproject/tor/src/ext/ed25519/ref10" "-L" "/home/travis/build/torproject/tor/src/ext/ed25519/donna" "-L" "/home/travis/build/torproject/tor/src/trunnel" "-L" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "-Wl,--whole-archive" "-l" "tor-crypt-ops-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-sandbox-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-encoding-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-fs-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-time-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-net-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-thread-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-memarea-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-log-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-lock-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-fdio-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-container-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-smartlist-core-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-string-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-malloc" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-wallclock" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-err-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-intmath-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "tor-ctime-testing" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "curve25519_donna" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "keccak-tiny" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "ed25519_ref10" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "ed25519_donna" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-l" "or-trunnel-testing" "-Wl,--no-whole-archive" "-Wl,-Bdynamic" "-l" "z" "-l" "m" "-l" "ssl" "-l" "crypto" "-l" "event" "-l" "lzma" "-l" "scrypt" "-l" "seccomp" "-l" "cap" "-l" "pthread" "-l" "dl" "-Wl,-Bstatic" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libtest-b66ae0f7ceefd4a4.rlib" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libterm-d827f4b0e7afdcf0.rlib" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libgetopts-beedc388f272415a.rlib" "/home/travis/build/torproject/tor/src/rust/target/debug/deps/libexternal-b51270571fdbe9aa.rlib" "/home/travis/build/torproject/tor/src/rust/target/debug/deps/libsmartlist-bef593dabcf59f69.rlib" "/home/travis/build/torproject/tor/src/rust/target/debug/deps/librand-dcbd058a5a82c6a4.rlib" "/home/travis/build/torproject/tor/src/rust/target/debug/deps/librand_core-ffccd4631e4e00cb.rlib" "/home/travis/build/torproject/tor/src/rust/target/debug/deps/liblibc-212792d827b59ce3.rlib" "/home/travis/build/torproject/tor/src/rust/target/debug/deps/libdigest-7a6c0b2ac402fc2f.rlib" "/home/travis/build/torproject/tor/src/rust/target/debug/deps/libgeneric_array-433158e47fbb9822.rlib" "/home/travis/build/torproject/tor/src/rust/target/debug/deps/libtypenum-4ef63ac97eea58b4.rlib" "-Wl,--start-group" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-0cce0e0e34e933aa.rlib" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-7bed87070cafeede.rlib" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-e76963fdf0c94daa.rlib" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-8cd3b0417a81fb26.rlib" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_system-387bd949d1b36a91.rlib" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-453d825a151d7dec.rlib" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-5235bf36189564a3.rlib" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-5725e7f9b84bd931.rlib" "-Wl,--end-group" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-874d313336916306.rlib" "-Wl,-Bdynamic" "-l" "util" "-l" "util" "-l" "dl" "-l" "rt" "-l" "pthread" "-l" "pthread" "-l" "gcc_s" "-l" "c" "-l" "m" "-l" "rt" "-l" "pthread" "-l" "util" "-l" "util"
  = note: /home/travis/build/torproject/tor/src/lib/libtor-crypt-ops-testing.a(src_lib_libtor_crypt_ops_testing_a-crypto_rand.o): In function `crypto_strongest_rand_raw':
          /home/travis/build/torproject/tor/src/lib/crypt_ops/crypto_rand.c:276: undefined reference to `__asan_handle_no_return'

Full log in https://api.travis-ci.org/v3/job/413659207/log.txt

Note: Travis is still on Trusty last I checked.

I think the correct incantation might actually be -fsanitize=address -static-libasan (and similar for ubsan). nickm, do you know what versions of gcc, clang, Rust you tested with?

Note: See TracTickets for help on using tickets.