Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by yorkwar

  1. It turns out that some 3rd party library has some memory using problem. Thanks all.
  2. Hi Alan, That's not the case. I checked the back trace. It's called in a SC_THREAD, not SC_METHOD.
  3. 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!
  4. 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?
  5. Hi, The code below in this function may be not appropriate. //get the interfaces bound to the top of the hierachical bind chain // NOTE: this could be the same socket if there is no hierachical bind m_used_sockets=get_hierarch_bind()->get_sockets(); IEEE-1666-2011 stated: In my case, I do some port binding in my sc_module's API of before_end_of_elaboration. Then, if tlm_utils::multi_passthrough_initiator_socket::before_end_of_elaboration() is called before the one in my sc_module, m_used_sockets may have the out-of-data of value. It still indicates that there's no binding for this socket. In fact, m_sockets really indicates that there's a binding now. Then subsequent usage of m_used_sockets may cause an error.
  • Create New...