Should I worry about one rule violation in the Rust executable reported by ASAN?

Question

I have a Rust executable that was compiled exclusively within the Rust ecosystem; no external C code or linked libraries, without using a compiler.

After compiling with ASAN on Linux, ASAN reports one rule violation (ODR). Should I worry about the correctness of my executable? What are some common problems? What are some corner cases?

I understand that since all my Rust dependencies were compiled before .rlib s, and because none of my codes are in a foreign language, and since none of my codes explicitly refers to foreign libraries, the compiler should have known everyone of my program symbol names at compile time, with the possible exception of the system libraries that it drags on its own and therefore should be in the know. Thus, I tend to ignore the ODR violation as "I can do nothing about it."

I cannot reproduce this example with minimal reproduction, and I just need an answer that gives me enough to determine if I need to take care of this.

The command I used to build / run using ASAN:

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

Error message (with deleted executable file name and file)

 ==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 is not from my mailboxes (and I don’t observe any bad behavior, therefore, I tend to not care), but I have a few interdependent mailboxes that are substituted here, and I'm not sure if this can reflect another sinister issue.