24.16.5. gem5 sanitation build
If there gem5 appears to have a C++ undefined behaviour bug, which is often very difficult to track down, you can try to build it with the following extra SCons options:
./build-gem5 --gem5-build-id san --verbose -- --with-ubsan --without-tcmalloc
This will make GCC do a lot of extra sanitation checks at compile and run time.
As a result, the build and runtime will be way slower than normal, but that still might be the fastest way to solve undefined behaviour problems.
Ideally, we should also be able to run it with asan with --with-asan, but if we try then the build fails at gem5 16eeee5356585441a49d05c78abc328ef09f7ace (with two ubsan trivial fixes I’ll push soon):
=================================================================
==9621==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 371712 byte(s) in 107 object(s) allocated from:
#0 0x7ff039804448 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10c448)
#1 0x7ff03950d065 in dictresize ../Objects/dictobject.c:643
Direct leak of 23728 byte(s) in 26 object(s) allocated from:
#0 0x7ff039804448 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10c448)
#1 0x7ff03945e40d in _PyObject_GC_Malloc ../Modules/gcmodule.c:1499
#2 0x7ff03945e40d in _PyObject_GC_Malloc ../Modules/gcmodule.c:1493
Direct leak of 2928 byte(s) in 43 object(s) allocated from:
#0 0x7ff03980487e in __interceptor_realloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10c87e)
#1 0x7ff03951d763 in list_resize ../Objects/listobject.c:62
#2 0x7ff03951d763 in app1 ../Objects/listobject.c:277
#3 0x7ff03951d763 in PyList_Append ../Objects/listobject.c:289
Direct leak of 2002 byte(s) in 3 object(s) allocated from:
#0 0x7ff039804448 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10c448)
#1 0x7ff0394fd813 in PyString_FromStringAndSize ../Objects/stringobject.c:88
#2 0x7ff0394fd813 in PyString_FromStringAndSize ../Objects/stringobject.c:
Direct leak of 40 byte(s) in 2 object(s) allocated from
#0 0x7ff039804448 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10c448)
#1 0x7ff03951ea4b in PyList_New ../Objects/listobject.c:152
Indirect leak of 10384 byte(s) in 11 object(s) allocated from
#0 0x7ff039804448 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10c448
#1 0x7ff03945e40d in _PyObject_GC_Malloc ../Modules/gcmodule.c:
#2 0x7ff03945e40d in _PyObject_GC_Malloc ../Modules/gcmodule.c:1493
Indirect leak of 4089 byte(s) in 6 object(s) allocated from:
#0 0x7ff039804448 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10c448)
#1 0x7ff0394fd648 in PyString_FromString ../Objects/stringobject.c:143
Indirect leak of 2090 byte(s) in 3 object(s) allocated from:
#0 0x7ff039804448 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10c448
#1 0x7ff0394eb36f in type_new ../Objects/typeobject.c:
#2 0x7ff0394eb36f in type_new ../Objects/typeobject.c:2094
Indirect leak of 1346 byte(s) in 2 object(s) allocated from:
#0 0x7ff039804448 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10c448)
#1 0x7ff0394fd813 in PyString_FromStringAndSize ../Objects/stringobject.c:
#2 0x7ff0394fd813 in PyString_FromStringAndSize ../Objects/stringobject.c:
SUMMARY: AddressSanitizer: 418319 byte(s) leaked in 203 allocation(s).
From the message, this appears however to be a Python / pyenv11 bug however and not in gem5 specifically. I think it worked when I tried it in the past in an older gem5 / Ubuntu.
--without-tcmalloc is needed / a good idea when using --with-asan: https://stackoverflow.com/questions/42712555/address-sanitizer-fsanitize-address-works-with-tcmalloc since both do more or less similar jobs, see also Memory leaks.