TWiki > Simulation > IPv6Suite > Main > Libcwd	TWiki webs: Main | TWiki | Know | Sandbox
	Simulation . { Changes | Index | Search | Go }

Libcwd

This is another GNU licensed tool that is relatively simple to use. The complications encountered were due to OMNeT++ (configure with --disable-magic and only debug OMNeT++ using the cmdenv libraries to stop libcwd from detecting invalid deallocations). The main idea is to define channels that can be selectively turned on during runtime. A channel is the mechanism to group sets of debug messages for different purposes. This is an effective replacement for the current mess with all the different macros to achieve a similar effect with conditional compilation.

libcwd is not a dependency during the release build. By removing the macro CWDEBUG and not linking with cwd shared library it allows the application to be compiled anywhere. However because of its usefulness in logging to streams, it would have been great had it worked on TRU64. The configure scripts require GNU gcc compiler. This may be due to the fact that libcwd has become a malloc logger/debugger too.

libcwd was able to solve the aforementioned bug in the simulation. By putting debug messages into all the ctors of IPv6Address the output messages were all logged into a logfile. From that I was able to figure out that the resource freed at the end was never allocated in the first place (by turning on the malloc channel showing the address of every allocation). However that pointer points to a variable on the stack. To pinpoint exactly which invocation of the ctor, the mechanism in libcwd for printing out the return address i.e. the function that invoked the ctor was used. This pinpointed the problem and further analysis and corrections were applied. Now if it could print out the whole stack trace too it would be very useful.

Web site: http://libcwd.sourceforge.net

Usage

Currently the toggling of the debug channels have been integrated into the XML config file at the top most element netconf.

<netconf debugChannel="debug.log:notice:xmlAddresses:UDPVidStrmSvr">

As the example shows the debug output is placed in the file debug-<pid>.log with notice, xmlAddresses and UDPVidStrmSvr channels turned on. For a complete list of debug channels available please consult Util/debug.cc for the actual channel names.

To log the allocations as early as possible would require that main() in main.cc of omnetpp be modified. That is done in our local CVS server. The following diff omnetpp-libcwd.diff shows the changes required to ensure libcwd does not assert on the incorrect usage of delete instead of delete [] in omnetpp itself. To turn on the early logging of allocations in memorytrace.log add -DEARLY_CWDEBUG in conjunction with -DCWDEBUG to turn libcwd on and link with libcwd (-lcwd).

However there are still assertions from libcwd at the static destruction level after main is exited, but I have no idea as to why (or whether it is valid) because at that point even libcwd does not output any debug hints but it's malloc/free overrides are still operational.