sc_report_handler sc_report_handler affects the simulation itself

[haase]

Dear all,

i am designing a network simulator where a lot of messages are flying around. For logging and debugging the states of the modules and the simulation i use the sc_report_handler class.

In main.cpp i set the following options:

sc_report_handler::set_verbosity_level(verbosity);
sc_report_handler::set_log_file_name("out.log");
sc_report_handler::set_actions(SC_INFO, SC_LOG);
sc_report_handler::set_actions(SC_WARNING, SC_LOG);

verbosity is a variable passed from a configuration file.

In my files/modules etc i have usually code like this to print into the log file:

std::stringstream ss;
ss << this->name() << " some message, maybe with variables like x: " << x;
SC_REPORT_INFO_VERB(msgId, ss.str().c_str(), sc_core::SC_DEBUG);

I use the stringstream to format like i want and set the verbosity. I have a lot

Before i start the simulation i read a configuration file with lots of parameters. There is also the verbosity level inside:

# Verbosity level
# None, Low, Medium, High, Full, Debug
verbosity = None

In my code i have several SC_REPORT_INFO_VERB commands with different verbosity levels, so that i can track different information on my needs for debugging.

Now to my problem/question:

Depending on the verbosity i get different simulation results. How the sc_report_handler can affect the simulation? Maybe i am doing something wrong, bit this behavious is really confusing for me.

Thank you very much.

[Eyck]

One reason I've seen in the past quite often are uninitialized local variables being used in the control flow:

int a;
...
unsigned b = a;
...
if(b>0){
  ...
} else {
  ...
}

Although b seems to be initialize it gets its value uninitialized. Hwo would logging effect this? Depending on the configuration the stack being used has different residual values (from previous funcion executions). Therefore 'a' gets different -unitialized- values which are later used to steer the control flow. Therefore my mantra is always: initialize variables upon declaration. In C++11 this becomes quite easy:
 

int a{0};
// or better:
auto a=0;

The use of auto requires an initialization whioch is enforce by the compiler then which is quite handy.

Aside of that: maybe you would want to have a look at https://github.com/VP-Vibes/SystemC-Components/blob/master/incl/scc/report.h and https://github.com/VP-Vibes/SystemC-Components/blob/master/src/report.cpp which provide a more convenient logging interface on top of the plain SystemC report infrastructure.

[haase]

Thank you for your fat reply.

I think some uninitialized variables could be the problem. I trying to check this, but this is really hard, because the code is quite big now. Is there a easy way to test such things automatically?

Thank you for the links, i will a look at it.

[Eyck]

Depends on the system youar eon and the compiler you are using. Here are a few options: https://stackoverflow.com/questions/2099692/easy-way-find-uninitialized-member-variables

Unfortunately the reports ar not exhaustive so there is still some work ahead....

[David Black]

Suggestions:

1. use stricter compilation rules such as -pedantic -Wall -Wextra and require all compilations to have zero warnings. This methodology will catch most errors. Use Ptah as to make exceptions around specific warnings you allow but only when you are certain and only for short code segments. 
2. Switch from g++ to clang++
3. Run static analysis and lint tools on your code 

Consider using Jetbrains’ CLion toolset. Inexpensive for what it does.