Ben Greear <[EMAIL PROTECTED]> wrote: > Pavlin Radoslavov wrote: > > > Please apply the patch below and see whether it solves the stale > > memory problem and/or some of the earlier problems. > > I took a different path but my fix is somewhat similar. > > I'm tracking down some more memory leaks found by valgrind > and hope to have a patch for review within the hour. I'll > post my patch, but if you prefer your method (and it works), > then that is fine too.
OK, I will wait for your patch and compare it with what I have before committing anything. > Did you get a chance to look at the bug_catcher logic? Any > interest in adding that? I think it will be useful for > catching future bugs & debugging core files. It's especially > nice for core files because you can print out the 'magic' member > and see if an item has been deleted or not.... I looked into it, but the downside of a solution like this is you have to modify the source code in the exact location you think there is a problem. Also, the only problem it seems to solve is deleting an object that has been deleted previously. This obviously makes its applicability very limited and I am not sure how much effort will be saved by using it. In fact, given that it typically requires modification of the *.hh header file with the class declaration, it might actually slow you down waiting for everything that depends on that header file to compile. Myself I am using similar hacks from time to time, but typically few simple "XLOG_INFO()" print messages are sufficient to tell me whether I am looking into the right direction. If it seems the problem is memory-related, then tools like valgrind should be used instead. Said that, I don't think we should push it into XORP because it might be of little value to other developers. Thanks, Pavlin _______________________________________________ Xorp-hackers mailing list [email protected] http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
