Skip to content

fix: log store only if it actually happened #1995

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

Merged

Conversation

arrv-sc
Copy link
Contributor

@arrv-sc arrv-sc commented May 20, 2025

Since 92e4f02 moved logging logic into store_slow_path function it has been logging stores even if actually_store parameter is false. Because of that logging is broken for all atomic instructions. Function amo calls store_slow_path with nullptr argument and actually_store equal to false while callee uses reg_from_bytes independently from actually_store value All of that causes dereferencing of nullptr. This commit logs memory access only if it actually happened.

This bug was found while trying to execute some code with atomics with --log-commits option (Made reproducer into a test in this commit). And getting segmentation fault. After rebuilding with address sanitizer got the following error:

AddressSanitizer:DEADLYSIGNAL
=================================================================
==14771==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x55886fe5d610 bp 0x62f00000e400 sp 0x7ffcad1ad2b8 T0)
==14771==The signal is caused by a READ memory access.
==14771==Hint: address points to the zero page.
    #0 0x55886fe5d610 in reg_from_bytes(unsigned long, unsigned char const*) riscv-isa-sim/riscv/mmu.cc:126
    #1 0x55886fe5fd4c in mmu_t::store_slow_path(unsigned long, unsigned long, unsigned char const*, xlate_flags_t, bool, bool) riscv-isa-sim/riscv/mmu.cc:373
    #2 0x55886ff20fae in amo<unsigned int, logged_rv64i_amoadd_w(processor_t*, insn_t, reg_t)::<lambda(uint32_t)> > riscv-isa-sim/riscv/mmu.h:180
    #3 0x55886ff20fae in logged_rv64i_amoadd_w(processor_t*, insn_t, unsigned long) riscv-isa-sim/riscv/insns/amoadd_w.h:2
    #4 0x5588701e51ca in execute_insn_logged riscv-isa-sim/riscv/execute.cc:174
    #5 0x5588701e51ca in processor_t::step(unsigned long) riscv-isa-sim/riscv/execute.cc:286
    #6 0x55886fe481f3 in sim_t::step(unsigned long) riscv-isa-sim/riscv/sim.cc:288
    #7 0x55886fe4834b in sim_t::idle() riscv-isa-sim/riscv/sim.cc:445
    #8 0x55887021cd24 in htif_t::run() riscv-isa-sim/fesvr/htif.cc:290
    #9 0x55886fdfd61a in main riscv-isa-sim/spike_main/spike.cc:551
    #10 0x7f432496ed8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    #11 0x7f432496ee3f in __libc_start_main_impl ../csu/libc-start.c:392
    #12 0x55886fe095d4 in _start (riscv-isa-sim/build/install/bin/spike+0x2825d4)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV riscv-isa-sim/riscv/mmu.cc:126 in reg_from_bytes(unsigned long, unsigned char const*)
==14771==ABORTING

Since 92e4f02 moved logging logic into store_slow_path function it has
been logging stores even if actually_store parameter is false. Because
of that logging is broken for all atomic instructions. Function "amo" calls
store_slow_path with nullptr argument and actually_store equal to false
while callee uses reg_from_bytes independently from actually_store value
All of that causes dereferencing of nullptr. This commit logs memory
access only if it actually happened
@arrv-sc arrv-sc force-pushed the arrv-sc/fix-store-segfault branch from ea6e9ae to 7d43d38 Compare May 20, 2025 14:40
Copy link
Collaborator

@aswaterman aswaterman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, and thank you for adding a test.

@aswaterman
Copy link
Collaborator

I uploaded the new test binary tarball.

@aswaterman aswaterman merged commit a07c190 into riscv-software-src:master May 21, 2025
3 of 6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants