Skip to content

Issue 702 regression tests GitHub actions cache#3

Open
erin-le wants to merge 14 commits intodevelopfrom
issue-702-regression-tests-github-actions-cache
Open

Issue 702 regression tests GitHub actions cache#3
erin-le wants to merge 14 commits intodevelopfrom
issue-702-regression-tests-github-actions-cache

Conversation

@erin-le
Copy link
Copy Markdown
Owner

@erin-le erin-le commented Aug 7, 2025

Code for tests that use the GitHub Actions cache to compare the current run's stats with the previous day's stats. Putting this somewhere safe so it doesn't get lost.

erin-le pushed a commit that referenced this pull request Aug 15, 2025
Apply construct-on-first-use scheme to address this issue.

==2940471==ERROR: AddressSanitizer: initialization-order-fiasco on address 0x00001bd22044 at pc 0x0000045b8041 bp 0x7ffefca16730 sp 0x7ffefca16728
READ of size 4 at 0x00001bd22044 thread T0
    #0 0x0000045b8040 in gem5::DrainManager::state() const gem5/sim/drain.hh:152
    #1 0x0000045b8040 in gem5::Drainable::Drainable() gem5/sim/drain.cc:199
    #2 0x000004790b13 in gem5::SimObject::SimObject() gem5/sim/sim_object.cc:71
    #3 0x000000926dee in DefaultRequestPort gem5/mem/port.cc:67
    #4 0x000000926dee in __static_initialization_and_destruction_0 gem5/mem/port.cc:110
    #5 0x000000926dee in _GLOBAL__sub_I__ZN4gem511RequestPortC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPNS_9SimObjectEs gem5/mem/port.cc:208
    #6 0x7fd81e6b6eba in call_init ../csu/libc-start.c:145
erin-le pushed a commit that referenced this pull request Aug 15, 2025
We can remedy this with proper initializations. The offending variable was
TargetList's canMergeWrites, but I also fixed up everything in MSHR.

gem5/mem/cache/mshr.hh:169:11: runtime error: load of value 8, which is not a valid value for type 'bool'
    #0 0x000003e0a992 in gem5::MSHR::TargetList::TargetList(gem5::MSHR::TargetList const&) gem5/mem/cache/mshr.hh:169
    #1 0x000003e0b84c in gem5::MSHR::MSHR(gem5::MSHR const&) gem5/mem/cache/mshr.hh:74
    #2 0x000003e0d83b in void std::_Construct<gem5::MSHR, gem5::MSHR const&>(gem5::MSHR*, gem5::MSHR const&) /spec/compilers/gcc-15.1.0/include/c++/15.1.0/bits/stl_construct.h:133
    #3 0x000003e0d83b in gem5::MSHR* std::__do_uninit_fill_n<gem5::MSHR*, unsigned long, gem5::MSHR>(gem5::MSHR*, unsigned long, gem5::MSHR const&) /spec/compilers/gcc-15.1.0/include/c++/15.1.0/bits/stl_uninitialized.h:470
erin-le pushed a commit that referenced this pull request Mar 12, 2026
Static storage duration objects that has non-trivial destructor are bad.
And a function-local static reference of the form static T& t = *new T;
is allowed
Reference for the style guide:
https://google.github.io/styleguide/cppguide.html#Static_and_Global_Variables

Background:
There's a segmentation fault on the arm server if I run the gem5
simulation with --dry-run, do m5.instantiation() but no m5.simulation().

Stack trace:
Thread 1 "gem5.opt" received signal SIGSEGV, Segmentation fault.
__GI_strcmp () at ../sysdeps/aarch64/strcmp.S:136
warning: 136    ../sysdeps/aarch64/strcmp.S: No such file or directory
(gdb) bt
#0  __GI_strcmp () at ../sysdeps/aarch64/strcmp.S:136
#1 0x0000aaaab415f424 in sc_gem5::(anonymous namespace)::findEventIn
(events=std::vector of length 2, capacity 2 = {...}, name="event_0") at
/usr/include/c++/14/bits/basic_string.h:227
#2 sc_gem5::(anonymous namespace)::popEvent (events=0xaaaac00aed50
<sc_gem5::topLevelEvents()::topLevelEvents>, name="event_0") at
src/systemc/core/event.cc:68
#3 sc_gem5::Event::~Event (this=0xaaaac1d8b000, __in_chrg=<optimized
out>) at src/systemc/core/event.cc:150
#4 0x0000aaaab417e95c in sc_core::sc_event::~sc_event (this=<optimized
out>, __in_chrg=<optimized out>) at src/systemc/core/sc_event.cc:321
#5  0x0000aaaabf7b39e0 in scx::async_request::~async_request() ()
#6 0x0000aaaabf7b12d4 in scx::scheduler_mapping::~scheduler_mapping() ()
#7 0x0000aaaabf7b1498 in scx::scheduler_mapping::~scheduler_mapping() ()
#8 0x0000aaaabf7adfb4 in scx::scx_simcontroller::~scx_simcontroller() ()
#9 0x0000ffffe7b5946c in __run_exit_handlers (status=0,
listp=0xffffe7cd0660 <__exit_funcs>,
run_list_atexit=run_list_atexit@entry=true,
run_dtors=run_dtors@entry=true) at ./stdlib/exit.c:118
#10 0x0000ffffe7b59560 [PAC] in __GI_exit (status=<optimized out>) at
./stdlib/exit.c:148
#11 0x0000ffffe7b42220 [PAC] in __libc_start_call_main
(main=main@entry=0xaaaab6af43a0 <main(int, char**)>, argc=argc@entry=15,
argv=argv@entry=0xffffffffeee8) at
../sysdeps/nptl/libc_start_call_main.h:74
#12 0x0000ffffe7b422fc [PAC] in __libc_start_main_impl
(main=0xaaaab6af43a0 <main(int, char**)>, argc=15, argv=0xffffffffeee8,
init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>,
    stack_end=<optimized out>) at ../csu/libc-start.c:360
#13 0x0000aaaab4003b30 [PAC] in _start ()

The issue seems to be the destruction order. There's a static
topLevelEvents() that will be used in Event() ctor with sc_event. The
segmentation fault happens when topLevelEvents already be destruct
before ~Event calling destructor that will use topLevelEvents.
@erin-le erin-le closed this Mar 26, 2026
@erin-le erin-le reopened this Mar 26, 2026
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.

1 participant