Should I care about a one-definition-rule violation in a Rust executable reported by ASAN?

Question

I have a Rust executable which was compiled purely within the Rust ecosystem; no external C code or linked libraries, sans whatever the compiler drags in.

After compiling it with ASAN on Linux, ASAN reports a one-definition-rule (ODR) violation. Should I have concerns about the correctness of my executable? What are some common concerns? What are some corner cases?

My understanding is that because all my Rust dependencies were compiled to .rlibs, and because none of my code is in a foreign language, and because none of my code explicitly refers to foreign libraries, the compiler should have been aware of all of my program's symbol names at compile time, with the possible exception of system libraries that it drags in itself and thus should be aware of. Thus I'm leaning towards ignoring the ODR violation as "nothing I can do about it."

I'm not able to produce a minimal repro example of this currently, and merely need an answer that gives me enough to determine whether or not I should care enough to investigate.

The command that I used to build/run with ASAN:

CARGO_INCREMENTAL=0 RUSTFLAGS="-Z sanitizer=address" cargo run --target x86_64-unknown-linux-gnu --example name_of_example

The error message (with the executable name and file path removed)

==18003==ERROR: AddressSanitizer: odr-violation (0x5625fb39f760):
  [1] size=0 'ref.c' executable_name_here12-d0d02bd82d5d1b2688ff68a1707ea7a1.rs
  [2] size=0 'ref.l' executable_name_here10-d0d02bd82d5d1b2688ff68a1707ea7a1.rs

These globals were registered at these points:
  [1]:
    #0 0x5625fb2a5727 in __asan_register_globals.part.11 /checkout/src/libcompiler_builtins/compiler-rt/lib/asan/asan_globals.cc:338
    #1 0x5625faf4e26d in asan.module_ctor (/executable/path/here+0x1c326d)

  [2]:
    #0 0x5625fb2a5727 in __asan_register_globals.part.11 /checkout/src/libcompiler_builtins/compiler-rt/lib/asan/asan_globals.cc:338
    #1 0x5625fae9d9cd in asan.module_ctor (/executable/path/here+0x1129cd)

As far as I can tell, this isn't from my crates (and I don't otherwise observe bad behavior, hence my leaning towards not caring) but I have multiple interdependent crates getting instrumented here, and am not sure if this could reflect some more sinister underlying problem.

Frydman

Could you explain which symbol ASAN reported? Is it a symbol from your crates or not? Is it a static value or a function? ... Your question is quite lacking in details at the moment :x – Incoming

@MatthieuM. Oh, yes, that would be important, wouldn't it... – Frydman

One Definition Rule is a rule of C and C++. Running the check on Rust executables doesn't make sense to me. – Huttan

@SebastianRedl If I understand well, that's the OP's question: "Does this concept make sense in Rust, and why?". You should elaborate your comment in an answer. – Cavalierly

@Cavalierly I don't want to make an answer since I don't know what the odr-checker actually does that makes it think Rust programs contain violations. The documentation isn't clear on the mechanism. – Huttan

@SebastianRedl based on my reading 1, 2, it does seem like something to be worried about. Why wouldn't having two symbols with different definitions matter to Rust? – Grafton

@Grafton So one interesting aspect is that ASAN reports two different names, 'ref.c' vs 'ref.l'. All the Wiki examples show the same name. If the names are different, how is that a conflict? The other part is that from my understanding of how Rust name mangling works, it shouldn't be possible to produce ODR violations at all, except with extern C symbols. My understanding may be faulty though. – Huttan

Also seems like the symbols in which the globals were registered (e.g. __asan_register_globals.part.11) don't occur in the code when compiling without ASAN (i.e. no -Z sanitizer=address), insofar as my grepping the output of nm on the compiled binaries for the string asan goes. I'm not sure, but this might be a bug in the ASAN hooks generated by rustc? I'unno. – Frydman