Debugging an sc_lv related crash

[richpodraza]

I am struggling to resolve a crash in some code I'm working on. I don't want to post the code just yet because I think I would need to post a lot of it in order to provide all the relevant details.

Here is a majorly simplified description:

- There is a structure that contains some sc_bv fields, as well as a deque< sc_lv<32> > called data.

- An instance of this structure is passed by constant reference to a function and is used to fill another buffer of the same size.

- After the other buffer is filled, accesses to this structure's other fields in a cout << operation crash. Keep in mind this is a constant reference object and no changes are made to it. The same cout << operation works fine before the other buffer is filled. EDIT: in fact, completely separate objects show the same behavior where accesses to them before work but after crash. It seems like a memory problem.

Now I know that is sparse information but based on the stacktrace below, can anyone hazard a guess about what's happening? So far I have verified that all the index values used when accessing both the deque and it's containing sc_lv objects are in-bounds, and I've verified that values within the structure are valid and print out before the buffer fill. Could I have a problem with my libc.so.6? Or another environment issue? A memory problem? Any suggestions on how to better debug this? Thanks!

GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /home/sc_hmc/sc_hmc...done.
[New LWP 8994]

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Core was generated by `./sc_hmc'.
Program terminated with signal 11, Segmentation fault.
#0  0x0043b10f in ?? () from /lib/i386-linux-gnu/libc.so.6
(gdb) where
#0  0x0043b10f in ?? () from /lib/i386-linux-gnu/libc.so.6
#1  0x0043dddc in malloc () from /lib/i386-linux-gnu/libc.so.6
#2  0x00e78627 in operator new(unsigned int) () from /usr/lib/i386-linux-gnu/libstdc++.so.6
#3  0x00e5d7d4 in std::string::_Rep::_S_create(unsigned int, unsigned int, std::allocator<char> const&) () from /usr/lib/i386-linux-gnu/libstdc++.so.6
#4  0x00e5eacf in std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned int) ()
  from /usr/lib/i386-linux-gnu/libstdc++.so.6
#5  0x00e5ebfe in std::string::reserve(unsigned int) () from /usr/lib/i386-linux-gnu/libstdc++.so.6
#6  0x00e5f316 in std::string::operator+=(char) () from /usr/lib/i386-linux-gnu/libstdc++.so.6
#7  0x08051ed5 in sc_dt::sc_proxy<sc_dt::sc_bv_base>::to_string (this=0x8b5ebf4)
at /home/systemc-2.3.0/include/sysc/datatypes/bit/sc_proxy.h:1325
#8  0x08053efa in sc_dt::sc_proxy<sc_dt::sc_bv_base>::print (this=0x8b5ebf4, os=...)
at /home/systemc-2.3.0/include/sysc/datatypes/bit/sc_proxy.h:452
#9  0x080529f3 in sc_dt::operator<< <sc_dt::sc_bv_base> (os=..., a=...)
at /home/systemc-2.3.0/include/sysc/datatypes/bit/sc_proxy.h:1524
#10 0x0805f678 in pkg_pkt::cls_req_pkt::build_pkt (this=0x8c19c70, cad=...,
credit_return=@0x8b5eaf8: 512, tag0=@0x8b5ed04: 0, seq=@0x8b5ed24: 0) at pkt.svp.cpp:409
#11 0x0813921b in pkg_drv::cls_drv::run_tx (this=0x8b5ea58) at pkg_drv.sv.cpp:205
#12 0x0017becf in sc_core::sc_thread_cor_fn(void*) ()
  from /home/systemc-2.3.0/lib-linux/libsystemc-2.3.0.so
#13 0x00163494 in sc_cor_qt_wrapper ()
  from /home/systemc-2.3.0/lib-linux/libsystemc-2.3.0.so
#14 0x00183740 in ?? () from /home/systemc-2.3.0/lib-linux/libsystemc-2.3.0.so

[David Black]

#2 suggests you ran out of memory allocating a new int...

[Philipp A Hartmann]

It's quite hard to tell the actual cause of the crash from your description and from the stacktrace alone. I assume a memory corruption in your part of the code.

• Do you store references or iterators to elements in the deque? Those can be invalidated by operations on the container.
  
• Are you sure, the object has not been destroyed? Dangling references can be quite hard to track down.
  
• Do you have a custom copy-constructor, assignment operator, or destructor in your class? Then you probably need all three of them (rule of three), to make it work correctly.
  

You should try to strip down your problem to a minimal, self-contained test case. Take your custom class and write a separate function trying to reproduce the problem. If this does not help, try to check the differences. Of course, you can post this example here to ask for feedback.

Greetings from Oldenburg,

Philipp

[dakupoto]

Hello,

Phillip has posted a number of very useful hints that

might lead to identifying the cause of the problem.

Please note that SystemC is basically a C++ library,

and hence all the subtle issues that cause C++

programs to fail apply to SystemC programs as well.

It might help to pare your code to a bare minimum

module that works, and then incrementally add

more features to it, checking after each such

addition that whatever was added did not cause a

crash. In this case, most of us are kept guessing

as the source code cannot be posted. Hope that

helps.

[richpodraza]

Thanks for the suggestions so far. I will try to reproduce in a smaller, manageable example and debug or post that. Also the tip about copy constructors and assignment operators is not something I've considered.

[richpodraza]

Regarding the Rule of Three here, none of my classes in question are managing their own resources. My classes all consist of types either from std or systemc. My understanding is the default assignment/copy/destructors for these should be sufficient as those classes that make up my class implement the resource management. Is that correct?

[Philipp A Hartmann]

Regarding the Rule of Three here, none of my classes in question are managing their own resources. My classes all consist of types either from std or systemc. My understanding is the default assignment/copy/destructors for these should be sufficient as those classes that make up my class implement the resource management. Is that correct?

Yes, this is correct and usually the right thing to do.

[richpodraza]

I eventually found my problem with this and of course it was a simple oversight. The code called resize() and clear() on a vector, in that order, and meant to do the opposite. However, the simulation wasn't crashing on accesses to the vector, it was crashing on an unrelated line, which is partly why it was so hard to spot! Thanks for the help along the way.