Re: [Valgrind-users] SystemC with valgrind?

[Julian S. <js...@ac...>]

Don't I know your name in connection with denotational semantics,
or something?

> (a)
> Has anyone had experience debugging SystemC programs with valgrind?
> Were there any unexpected problems?

Umm ... what's systemC ?

> (b)
> Can anyone suggest what I should do next with the following problem?
>
> I have a SystemC program which maintains a number of queues, implemented
> as C++ list<packet *>.  gdb reveals that after the simulation has been
> running for a considerable time, I create and initialise a packet and
> put it on the back of one queue, but a packet with the same pointer is
> already at the front of a quite different queue and has its contents
> overwritten.  (All queues and packets are in storage around 0x8,000,000.)
>
> This looks like a classic case of premature deletion, so I try to find
> it with valgrind.  But valgrind produces an "invalid read" error a
> little bit earlier in the simulation, and gdb shows all the packets in
> the queue about to be clobbered have now been moved to invalid addresses
> around 0x43,000,000.  (Valgrind guesses that this address is "on thread
> 1's stack", but I'm not sure that's reliable.)
>
> Running without valgrind shows, according to gdb at the relevant moment,
> no sign of this relocation.
>
> So I reckon that if the packets have turned up in the new place,
> something (presumably with access rights) must have put them there.  So
> I try again with the offending address made invalid by a
> VALGRIND_MAKE_NOACCESS call, hoping to catch whatever it is that wrote
> them in the first place.  But the program fails in the same place as
> before (though this time the error is because I've declared the address
> invalid, not because valgrind thought it was invalid anyway).  The
> packets are all there at the new place, with their proper contents; but
> whatever it is that wrote them there snuck in under my prohibition.
>
> Sorry to go on at length, but I'm a bit stuck.  I'd be grateful for any
> suggestions . . .

3 comments.

1. Increase valgrind's --freelist-vol parameter to as large a number
   as you can.  The manual describes what it is and why this might
   be useful.   (do  valgrind --skin=memcheck --help, assuming you
   are using v-1.9.4).

2. If you are doing this VALGRIND_MAKE_NOACCESS with valgrind version
   1.1.0 or later, we found recently a bug in which the file to 
   include is "memcheck.h" and not "valgrind.h".  The real bad thing
   is that including "valgrind.h" still seems to work, but strange
   things happen at run time.  I've put in a fix to both the head
   and 2_0_BRANCH to cause a compilation error if you include valgrind.h
   directly, and that will be in 1.9.5.

3. As Nick rightly points out, make friends with GDB's hardware 
   watchpoints if you haven't already.  In summary, 
      watch *(int*) 0xAddressToWatch
   They've saved my ass on various occasions since I learnt of them.

J