search

mmtk / mmtk-core

Memory Management ToolKit
https://www.mmtk.io
Other
379 stars 69 forks source link

ASAN reports READ segfault #1088

Closed riking closed 7 months ago

riking commented 9 months ago

Hello, your tests from an old version (0.18.0) crash under AddressSanitizer:

https://asan.saethlin.dev/ub?crate=mmtk&version=0.18.0

Please check whether this crash still applies to the current version! (I couldn't find any existing issues discussing this.)

test util::metadata::side_metadata::global::tests::test_u16_atomic_store ... AddressSanitizer:DEADLYSIGNAL
=================================================================
==4968==ERROR: AddressSanitizer: SEGV on unknown address 0x018087ff8000 (pc 0x55a9f0f9a513 bp 0x7f0af1cf43d0 sp 0x7f0af1cf4320 T227)
==4968==The signal is caused by a READ memory access.
    #0 0x55a9f0f9a513 in mmtk::util::metadata::side_metadata::global::tests::test_side_metadata::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::hd75dd30daa1f0d50 /build/src/util/metadata/side_metadata/global.rs:1155:30
    #1 0x55a9f114ef00 in mmtk::util::test_util::with_cleanup::h9df2567382e0827e /build/src/util/test_util.rs:100:5
    #2 0x55a9f0f1ce47 in mmtk::util::metadata::side_metadata::global::tests::test_side_metadata::_$u7b$$u7b$closure$u7d$$u7d$::h85469e4007ef4fee /build/src/util/metadata/side_metadata/global.rs:1144:13
    #3 0x55a9f10f4a86 in mmtk::util::test_util::serial_test::h847064f0cafbf488 /build/src/util/test_util.rs:90:5
    #4 0x55a9f0eedfcf in mmtk::util::metadata::side_metadata::global::tests::test_side_metadata::hd03e6fdcfae2ee5a /build/src/util/metadata/side_metadata/global.rs:1127:9
    #5 0x55a9f0fce1da in mmtk::util::metadata::side_metadata::global::tests::test_u16_atomic_store::ha1ecccc3a8eb991d /build/src/util/metadata/side_metadata/global.rs:1214:21
    #6 0x55a9f0fce1b2 in mmtk::util::metadata::side_metadata::global::tests::test_u16_atomic_store::_$u7b$$u7b$closure$u7d$$u7d$::h980a02e4e046e4f6 /build/src/util/metadata/side_metadata/global.rs:1213:46

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /build/src/util/metadata/side_metadata/global.rs:1155:30 in mmtk::util::metadata::side_metadata::global::tests::test_side_metadata::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::hd75dd30daa1f0d50
==4968==ABORTING
qinsoon commented 9 months ago

Thanks for the report. This issue can be reproduced on the current versionn (0.23, 86a94ca502594d078b35c29ea3d1d68b34f16a28).


yilin@rat:~/Code/mmtk-core$ RUSTFLAGS="-Z sanitizer=address" cargo +nightly test --target x86_64-unknown-linux-gnu -- util::metadata::side_metadata::global::tests::test_u16_atomic_store
    Finished test [unoptimized + debuginfo] target(s) in 0.06s
     Running unittests src/lib.rs (target/x86_64-unknown-linux-gnu/debug/deps/mmtk-320a5c946a55f37c)

running 1 test
AddressSanitizer:DEADLYSIGNAL
=================================================================
==137718==ERROR: AddressSanitizer: SEGV on unknown address 0x018087ff8000 (pc 0x555bf1c1c28a bp 0x7efc4fafde10 sp 0x7efc4fafdd40 T1)
==137718==The signal is caused by a READ memory access.
    #0 0x555bf1c1c28a  (/home/yilin/Code/mmtk-core/target/x86_64-unknown-linux-gnu/debug/deps/mmtk-320a5c946a55f37c+0x92428a) (BuildId: 6961ca7e00eb1597651cea1dc17a32c7e4546cd2)
    #1 0x555bf167540d  (/home/yilin/Code/mmtk-core/target/x86_64-unknown-linux-gnu/debug/deps/mmtk-320a5c946a55f37c+0x37d40d) (BuildId: 6961ca7e00eb1597651cea1dc17a32c7e4546cd2)
    #2 0x555bf1b8f02c  (/home/yilin/Code/mmtk-core/target/x86_64-unknown-linux-gnu/debug/deps/mmtk-320a5c946a55f37c+0x89702c) (BuildId: 6961ca7e00eb1597651cea1dc17a32c7e4546cd2)
    #3 0x555bf15ef560  (/home/yilin/Code/mmtk-core/target/x86_64-unknown-linux-gnu/debug/deps/mmtk-320a5c946a55f37c+0x2f7560) (BuildId: 6961ca7e00eb1597651cea1dc17a32c7e4546cd2)
    #4 0x555bf1b63e4f  (/home/yilin/Code/mmtk-core/target/x86_64-unknown-linux-gnu/debug/deps/mmtk-320a5c946a55f37c+0x86be4f) (BuildId: 6961ca7e00eb1597651cea1dc17a32c7e4546cd2)
    #5 0x555bf184db3a  (/home/yilin/Code/mmtk-core/target/x86_64-unknown-linux-gnu/debug/deps/mmtk-320a5c946a55f37c+0x555b3a) (BuildId: 6961ca7e00eb1597651cea1dc17a32c7e4546cd2)
    #6 0x555bf1c4b4b6  (/home/yilin/Code/mmtk-core/target/x86_64-unknown-linux-gnu/debug/deps/mmtk-320a5c946a55f37c+0x9534b6) (BuildId: 6961ca7e00eb1597651cea1dc17a32c7e4546cd2)
    #7 0x555bf1b1964b  (/home/yilin/Code/mmtk-core/target/x86_64-unknown-linux-gnu/debug/deps/mmtk-320a5c946a55f37c+0x82164b) (BuildId: 6961ca7e00eb1597651cea1dc17a32c7e4546cd2)
    #8 0x555bf1e16ffe  (/home/yilin/Code/mmtk-core/target/x86_64-unknown-linux-gnu/debug/deps/mmtk-320a5c946a55f37c+0xb1effe) (BuildId: 6961ca7e00eb1597651cea1dc17a32c7e4546cd2)
    #9 0x555bf1e15f74  (/home/yilin/Code/mmtk-core/target/x86_64-unknown-linux-gnu/debug/deps/mmtk-320a5c946a55f37c+0xb1df74) (BuildId: 6961ca7e00eb1597651cea1dc17a32c7e4546cd2)
    #10 0x555bf1dde2f5  (/home/yilin/Code/mmtk-core/target/x86_64-unknown-linux-gnu/debug/deps/mmtk-320a5c946a55f37c+0xae62f5) (BuildId: 6961ca7e00eb1597651cea1dc17a32c7e4546cd2)
    #11 0x555bf1de3446  (/home/yilin/Code/mmtk-core/target/x86_64-unknown-linux-gnu/debug/deps/mmtk-320a5c946a55f37c+0xaeb446) (BuildId: 6961ca7e00eb1597651cea1dc17a32c7e4546cd2)
    #12 0x555bf2bccc54  (/home/yilin/Code/mmtk-core/target/x86_64-unknown-linux-gnu/debug/deps/mmtk-320a5c946a55f37c+0x18d4c54) (BuildId: 6961ca7e00eb1597651cea1dc17a32c7e4546cd2)
    #13 0x555bf155132a  (/home/yilin/Code/mmtk-core/target/x86_64-unknown-linux-gnu/debug/deps/mmtk-320a5c946a55f37c+0x25932a) (BuildId: 6961ca7e00eb1597651cea1dc17a32c7e4546cd2)
    #14 0x7efc52a94ac2  (/lib/x86_64-linux-gnu/libc.so.6+0x94ac2) (BuildId: a43bfc8428df6623cd498c9c0caeb91aec9be4f9)
    #15 0x7efc52b26a3f  (/lib/x86_64-linux-gnu/libc.so.6+0x126a3f) (BuildId: a43bfc8428df6623cd498c9c0caeb91aec9be4f9)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/home/yilin/Code/mmtk-core/target/x86_64-unknown-linux-gnu/debug/deps/mmtk-320a5c946a55f37c+0x92428a) (BuildId: 6961ca7e00eb1597651cea1dc17a32c7e4546cd2) 
Thread T1 created by T0 here:
    #0 0x555bf153926d  (/home/yilin/Code/mmtk-core/target/x86_64-unknown-linux-gnu/debug/deps/mmtk-320a5c946a55f37c+0x24126d) (BuildId: 6961ca7e00eb1597651cea1dc17a32c7e4546cd2)
    #1 0x555bf2bcca9e  (/home/yilin/Code/mmtk-core/target/x86_64-unknown-linux-gnu/debug/deps/mmtk-320a5c946a55f37c+0x18d4a9e) (BuildId: 6961ca7e00eb1597651cea1dc17a32c7e4546cd2)

==137718==ABORTING
error: test failed, to rerun pass `--lib`

Caused by:
  process didn't exit successfully: `/home/yilin/Code/mmtk-core/target/x86_64-unknown-linux-gnu/debug/deps/mmtk-320a5c946a55f37c 'util::metadata::side_metadata::global::tests::test_u16_atomic_store'` (exit status: 1)
note: test exited abnormally; to see the full output pass --nocapture to the harness.
yilin@rat:~/Code/mmtk-core$ cargo +nightly --version
cargo 1.76.0-nightly (71cd3a926 2023-11-20)
qinsoon commented 7 months ago

I think this is a false alarm, and the reason is that we are using the address range in ASAN's shadow memory.

ASAN divides the address space into a few ranges. It reserves some ranges as shadow memory (metadata) so it can map other address ranges to a byte in the shadow memory. On x86_64, the following is what ASAN uses (ASAN_OPTIONS=verbosity=1 prints this). Basically we are allowed to use address ranges in HighMem and LowMem, but not the range in shadow memory. ShadowGap is by default protected (and are not allowed to use), but can be unprotected by ASAN_OPTIONS=protect_shadow_gap=false.

|| `[0x10007fff8000, 0x7fffffffffff]` || HighMem    ||
|| `[0x02008fff7000, 0x10007fff7fff]` || HighShadow ||
|| `[0x00008fff7000, 0x02008fff6fff]` || ShadowGap  ||
|| `[0x00007fff8000, 0x00008fff6fff]` || LowShadow  ||
|| `[0x000000000000, 0x00007fff7fff]` || LowMem     ||

MMTk currently uses 0x020000000000 to 0x220000000000, which clashes with HighShadow. Also the address range we use for side metadata starts from 0x0c0000000000, also clashes with HighShadow (it also clashes with the 6th space. See https://github.com/mmtk/mmtk-core/issues/458).

The line that ASAN reported was actually when we try to access side metadata at 0x0c0080000000 which is in the HighShadow. ASAN reported SEGV at 0x01808fff8000, which is a wrong address -- likely because we use addresses in the shadow memory and breaks their assumption on address arithmetic.

We could move the address range we use so it complies with ASAN which may not be a bad idea. But generally, I don't feel ASAN will be very helpful to us. It detects a few kinds of memory issues related with malloc so it only detects issues in the Rust code and possibly only unsafe code we have). It might be interesting to us that ASAN allows users to manually poison memory -- so theoretically, we can use ASAN to check MMTk heap objects. ASAN works in a way that is similar to the VO bit for MMTk's allocated objects. We could consider implement something more powerful than VO bit and similar to ASAN in MMTk so we can check for MMTk allocated objects.