|
From: Joe S. <st...@sa...> - 2003-03-21 15:35:20
|
Julian Seward wrote: > Don't I know your name in connection with denotational semantics, or > something? Yes, that's me. Seems a while ago now. > Umm ... what's systemC ? It's a system for simulation of hardware and other designs, built on top of C++. From http://www.systemc.org: "SystemC is the standard design and verification language built in C++ that spans from concept to implementation in hardware and software. Designers design and verify using SystemC and standard ANSI C++. EDA vendors create tools that are automatically interoperable." I had written: >> Can anyone suggest what I should do next with the following >> problem? I have now sorted this out, thank you. It was indeed a classic premature-deletion bug. I think Valgrind comes out with an "A-double-minus" grade. It gets a basic A because it did indeed detect the invalid use of memory which had already been freeed. But it doesn't quite get a straight A because: 1. It got confused about the error message (presumably because of the multi-threading). It ought to have told me simply that it was memory in the free store which I'd already deallocated; instead it went on about how it was from another thread's stack area. 2. My setting the address invalid, by VALGRIND_MAKE_NOACCESS, seemed not to affect my claiming it, using it and releasing it; it was only when I used it after that that the error message told me it was because I had invalidated it. (Maybe that's part of the bug Julian mentions in his message -- I had indeed included "valgrind.h", not "memcheck.h".) 3. The documentation emphasises that the system is designed to be "as non-intrusive as possible". I did not therefore realises that it nevertheless alters all the memory addresses used. This should perhaps be emphasised -- after all, if you're investigating memory usage errors, addresses tend to be relevant. Julian and Nick gave me helpful advice about gdb (some of which I was already doing). But the tricky part was hunting down where I had prematurely deleted the item. Two ways came to mind: 1. If the program was already printing lots of diagnostic output, run with Valgrind's --trace-malloc=yes. Then you can search for the delete, and see which of your own messages surround it. 2. If you know the type of the errant object, you can write code in its destructor to break for the case you're looking for. But these are both a little bit clunky. Perhaps a Valgrind option to do it more cleanly would be nice. I'm not sure. Anyway, thanks again for your help. joe stoy |