In Specman you would usually see something like:
*** Error: OS signal 11 (segmentation violation) received
See the stack trace in ./specman.err
o Rerun the same test with the same seed in interpreted mode, after
setting "break on error". Load also any previously compiled modules.
** One user module is compiled.
o For help on debugging e code, see "Debugger Commands" and "Source
Code Debugging" in the online help.
o If any user C code is linked into the Specman environment, try
debugging it using a C debugger to ensure that you are not accessing
any null pointers or memories not allocated by the C program.
If the problem is still not resolved, please send to Cadence support :
1. Description of how you have tried to resolve the problem
(Error itself might vary, as we will see shortly)
However, there are some things you can do in such cases that will help you to either resolve the issue, or narrow it down so that Cadence Support can find a faster resolution.
In such event of a Specman crash, Specman will create a specman.err file. Your overall goal would be to determine the cause of the crash and then try to correct or eliminate the cause.
This post comes to help you understand what the elements in the Specman error report are, and how to use the report details, in order to identify the cause and what actions to take.
When Specman crashes, it creates an error report file (specman.err) in the run directory. This file contains the information that can help you identify the cause of the error, so that you can take steps to correct or eliminate the problem.
This specman.err file includes the following parts:
Following a Specman crash, first thing you should do is examine the specman.err file, proceeding in the following sequence:
This post specifies problem identification, and will provide handling guidelines, for the following error types:
Let's say you got an OS signal 11 error:
OS signal 11 (segmentation violation) at Tue Aug 10 10:46:37 2010
OS signal 11 (segmentation violation) received
As stated in the error message, the first thing to do is check is if the crash happened in compiled mode (that is, if the e-testbench is compiled):
If the crash persists also after trying one of the above and you don't get any meaningful message, you will need to analyze the crash.
***** Interpreted stack trace:
( 0) 0x85f2601 ahb_create_instance + 0x9 [./libahb_mytb.so]
If (2) or (3) are correct, it probably means that the error comes from your C code, and you now need to debug your own library/C code. In this case:
For more information regarding debugging C Interface code, please refer to "Incisive Enterprise Specman Elite Testbench Integrators Guide", Chapter 1.16 - Debugging C/C++ Code
The following is an example of an OS 11 message issued during garbage collection (GC). This error hints that GC probably found inconsistency with the e types that might have been caused by a memory corruption.
Internal Error at Wed Nov 9 04:40:14 2011
: Fatal error
OS signal 11 (segmentation violation) during garbage collection - must exit.
The following is an example of an Unhandled OS signal 11 message:
OS signal 11 (segmentation violation) at Wed Mar 10 13:26:05 2010
Internal Specman Error: unhandled OS signal 11 (segmentation violation).
An unhandled OS signal 11 message often indicates that Specman caught an OS signal which it should not have - for example, a signal that was sent to a third-party tool or to the simulator.
You should examine the User View stack trace and the Interpreted stack trace and see where they point.
In the following example, the User View stack trace clearly points to the simulator:
***** User View stack trace:
( 0x0) simulator
In another example, the Interpreted stack trace points to the simulator:
( 0) 0x80c42bc
( 1) 0x80c4a0e
( 2) 0x80c5ef5
( 3) 0x80c635e
( 4) 0x839d775
( 5) 0x86a3612 TclInvokeStringCommand + 0x73 [ncsim]
( 6) 0x86a4f5f
( 7) 0x86a597f Tcl_EvalEx + 0x36e [ncsim]
( 8) 0x86a617f Tcl_EvalObjEx + 0x19f [ncsim]
In order to identify the actual source of the crash, set environment variable SN_HANDLE_ALL to none (‘setenv SN_HANDLE_ALL none'), and then rerun. This instructs Specman not to catch any signal; this will allow other tools to catch their signals, and might also facilitate a more informative stack. Note: This flag should only be used for debug purposes.
The following is an example of the messages issued when Specman reaches the user-defined maximum memory allowance granted to Specman (absolute_max_size):
Internal Error at Mon Nov 7 22:29:34 2011
Total memory requested from operating system
exceeds get_config(memory,absolute_max_size) (5242880000)
You should try to determine why the memory's absolute_max_size was reached. For example, it might be that
To resolve the later memory consumption problem, search for "Specman memory consumption is too high" in Specman documentation, and ascertain what steps you should take to tackle the problem.
Although there is little you can do if a bug in a Specman module causes an internal error, there are some steps you can take in order to help Cadence Support identify the issue faster.
Internal errors are generally accompanied by additional information that helps to narrow the suspected area of code. If an internal error ((a) in the message below) is accompanied by a message that points to a line in an internal Specman module (d), it generally indicates that the error was caused by a bug in that Specman module (which is detailed in (b) and (c)).
The accompanying User View stack trace shows the calls which lead to the crash:
( 0) analyzing constraint at line 39 in @intc_basic_types
( 1) gen context #145 tb_env_config_s
( 2) generation static analysis (finalize)
( 3) generation static analysis
( 4) pre specman run
( 5) specman
When you encounter a Specman internal error, you should send the specman.err file to Cadence Support, along with the module file to which the User View stack trace points to. If you cannot send the module file, try sending the code around the line in that module to which the User View stack trace points.
Semadar Sadeh & Avi Farjoun