Email about SIGSEGV
[All names, paths and addresses below are changed to respect privacy and secrets of humans, corporations and bytes]
Hi %Username%, The log you show has two error messages, and I believe the second one is induced by the first one. Let me illustrate.
running> Segmentation fault (SIGSEGV) in thread 0x7fff0415a700
#0 0x00007fff63ebca2b (/tmp/project/linux64/lib/dev_lib.so + 0x29da2b)
#1 0x00007fff10405490
The simulation state has been corrupted. Simulation cannot continue.
Please restart Simics.
This is the first problem: a bug somewhere inside dev_lib.so caused a segmentation violation, reported via an OS signal. By default, an application getting the signal is terminated immediately, but in Simics a non-default signal handler is registered. Its purpose is to be more gentle: 1) to print a call stack (which you can see), 2) to stop the simulation (done), to explain the situation to the user (done) and 3) to return the control to the user so that any unsaved information may be salvaged and/or additional state inspection can be done before exiting. However, the last step failed on its own:
running> *** THREAD: SIM_set_frontend_context: /disk/simics/common/fatal.c:476 called in execution context
*** ASSERTION ERROR:
/disk/simics/common/machine.c:264:
This is the second error message you’ve observed.
Note that after the first error, the application’s state is undefined and it may be corrupted beyond any repair, e.g. the whole memory filled with garbage, including the signal handler itself I’ve talked earlier.
Because of that, any action Simics (or any other regular user application, really) can take after a SIGSEGV has been seen is not guaranteed to succeed. Even a simple printf() might not work when the state is known to be corrupted to an unknown extent. Because of that, it does not make sense to attempt fixing the second problem (a failure to return to the command line). The escape-to-CLI logic works for other types of signals (e.g. SIGABORT), which is its intended use case. For SIGSEGV, we are lucky already to see the call stack at all, without a debugger attached.
What needs to be addressed is the first problem: the bug/corruption causing the segmentation fault. Please contact the module owner for further assistance.
I hope this helps.