Weird SystemC Context

[yorkwar]

Hi,

 

I have some models built against SystemC-2.3.1.

During simulation, I get an error telling me "in SC_METHODS use next_trigger() instead".

I set a breakpoint there, and check cpi->kind. It's "sc_core::SC_THREAD_PROC_". I'm puzzled why the switch case pattern goes to the default case (in wait(const sc_time&t, const sc_event& e, sc_simcontext* simc) of the file sc_wait.cpp), which causes the error.

 

At the same time, there's another odd thing. Through backtrace of GDB, I see

#0 sc_core::wait (t=..., e=..., simc=0x399f010)

#1 sc_core::sc_module::wait (this=0x3fee1d0, t=..., e=...)

#2 my_module:my_thread (this=0x3fee1d0)

#3 sc_core::sc_process_b::semantics (this=0x4046170)

#4 sc_core::sc_thread_cor_fn (arg=0x4046170)

#5 sc_core::sc_cor_qt_wrapper (arg=0x4046170, cor=0x46765e0, fn=...)

#6 qt_blocki ()

 

So, it should be in the SystemC thread of my_module::my_thread.

However, I checked sc_core::sc_curr_simcontext->get_curr_proc_info()->process_handle->m_name in GDB, it shows that it is the name of another thread.

 

I checked the program with Valgrind. It only shows some invalid read, no error with write.

Anything wrong?

[Roman Popov]

Something is messed up in your simulation, but It's hard to say without source code to debug.

Try to track who and when updates process_handle and why there is an sc_method there.

[yorkwar]

Thank you for your response.

 

There are some SC_METHODs in my simulation, cause it is a light wight SystemC process.

But at that time when the error occurs, as cpi->kind indicates, that should be a SC_THREAD.

 

There must be some memory pollution problem that is hard to find.

Any hint is greatly appreciated!

[apfitch]

The error message implies that you are calling wait() in your SC_METHOD - that's not allowed, wait() can only be called in SC_THREADS,

 

regards

Alan

[yorkwar]

The error message implies that you are calling wait() in your SC_METHOD - that's not allowed, wait() can only be called in SC_THREADS,

 

regards

Alan

 

Hi Alan,

That's not the case. I checked the back trace. It's called in a SC_THREAD, not SC_METHOD.

[apfitch]

Ok, as Roman says above, it's hard to help without the source code.

 

This might be obvious, but if you can't post the code, I would try the following

1. Try the same code on a different compiler and/or OS

2. Try to narrow down exactly what line of code is causing the problem by commenting out code until the problem disappears

3. Try setting breakpoints progressively further in the simulation until you can set a breakpoint just before the failure

 

regards

Alan

[yorkwar]

It turns out that some 3rd party library has some memory using problem.

Thanks all.