File: index.html

package info (click to toggle)
libcwd 1.0.4-1.1
links: PTS
area: non-free
in suites: jessie, jessie-kfreebsd
size: 8,136 kB
ctags: 10,313
sloc: cpp: 23,354; sh: 9,798; ansic: 1,172; makefile: 852; exp: 234; awk: 11
file content (674 lines) | stat: -rw-r--r-- 43,696 bytes
parent folder | download | duplicates (2)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML LANG="en-us">

<HEAD>
<META name="Author" content="Carlo Wood">
<META http-equiv="content-type" content="text/html; charset=iso-8859-1">
<TITLE>libcwd: The C++ Debugging Support Library</TITLE>
<!-- SCRIPT TYPE="text/javascript" SRC="scripts/xbDebug.js"></SCRIPT -->
<SCRIPT TYPE="text/javascript" SRC="scripts/break_out_of_frame.js"></SCRIPT>
<SCRIPT TYPE="text/javascript" SRC="scripts/detect_browser.js"></SCRIPT>
<SCRIPT TYPE="text/javascript">need_style_tag_cw=1;</SCRIPT>
<SCRIPT TYPE="text/javascript" SRC="scripts/load_style_sheets.js"></SCRIPT>
</HEAD>

<BODY>

<TABLE border=0 cellspacing=15 cellpadding=0 width=100%>

<!-- *** Page Header *** -->
<TR><TD class="tag-cw-main-header" colspan=2>
<table border=0 cellspacing=0 cellpadding=0 width=100%>
<tr><td width=88>&nbsp;</td>
    <td class="tag-cw-main-header" align=middle><B><SPAN class="H1code">libcw<FONT color=red>d</FONT></SPAN></B></td>
    <td width=88><IMG width=88 height=31 src="http://svn.alinoe.com/cwdtr/alinoe.png" border=0 alt="an alinoe production" width=88 height=31 align=right></td>
</tr></table>
</TD></TR>

<!-- *** Left column width *** -->
<TR><TD width=25% valign=top>

<table class="tag-cw" border=0 cellspacing=0 cellpadding=0 width=100%><tr><td>

<!-- *** Table Header top-left *** -->
<table width=100% cellpadding=5 border=0><tr><td class=tag-cw-header>
<span class="tag-cw-header-first">L</span>INKS
</td></tr></table>

</td></tr><tr><td>

<!-- *** Table Contents bottom-left *** -->
<table width=100% cellpadding=5 border=0><tr><td class="tag-cw-inner">
Home Page<BR>
<A href="www/features.html">Features</A><BR>
<A href="www/features.html#screenshot">&quot;Screenshot&quot;</A><BR>
<A href="tutorial/index.html">Tutorial</A><BR>
<A href="reference-manual/index.html">Reference Manual</A><BR>
<A href="www/quickreference.html">Quick Reference</A><BR>
<A href="http://sourceforge.net/project/showfiles.php?group_id=47536">Download</A><BR>
<A href="http://sourceforge.net/mail/?group_id=47536">Mailinglists</A>
</td></tr></table>

</td></tr></table>
<br>
<TABLE class="tag-cw" border=0 cellspacing=0 cellpadding=0 width=100%><tr><td>

<!-- *** Table Header bottom-left *** -->
<table width=100% cellpadding=5 border=0><tr><td class=tag-cw-header>
<span class=tag-cw-header-first>D</span>ESCRIPTION
</td></tr></table>

</td></tr><tr><td>

<!-- *** Table Contents top-left *** -->
<table width=100% cellpadding=5 border=0><tr><td class="tag-cw-inner">
Libcwd is a thread-safe, full-featured debugging support library for C++ developers.&nbsp;
It includes ostream-based debug output with custom debug channels and devices,
powerful memory allocation debugging support,
as well as run-time support for printing <I>source file</I><SPAN class="code">:</SPAN><I>line number</I>
information and demangled type names.
</td></tr></table>

</td></tr></TABLE>

<!-- *** Right column width *** -->
</TD><TD rowspan=2 width=75% valign=top>
<table class="tag-cw" border=0 cellspacing=0 cellpadding=0 width=100%><tr><td>

<!-- *** Table Header top-right *** -->
<table width=100% cellpadding=5 border=0><tr><td class=tag-cw-header>
<span class=tag-cw-header-first>N</span>EWS
</td></tr></table>

</td></tr><tr><td>

<!-- *** Table Contents top-right *** -->
<table width=100% cellpadding=5 border=0><tr><td class="tag-cw-inner">
<DT><B>2 Jun 2010</B>
<P class="news">libcwd-1.0.4 is released.&nbsp;
This version fixes the problem that occurred with the initialization of libcwd
with the lastest libc (2.10) because that calls dlopen before calling malloc et al.
It also fixes a bug in the internal read/write lock implementation that theoretically
could lead to dead locking of libcwd.
</P>
<DT><B>28 Jul 2009</B>
<P class="news">libcwd-1.0.3 is released.&nbsp;
This version fixes a vew bugs.&nbsp;
The most important bug being fixed involved a crash
while accessing a deleted <code>memblk_map_ct</code> in <code>search_in_maps_of_other_threads</code>.
</P>
<P class="news">If there are still undeleted memory allocations when a thread is destroyed, then its
<code>thread_ct</code> object is not removed from the thread list that <code>search_in_maps_of_other_threads</code> searches
but it is flagged as a 'zombie'. As soon as the last memory allocation is deleted
its <code>memblk_map_ct</code> is deleted (cleanup) but the <code>thread_ct</code> was not
removed from the thread list, causing a crash the next call to <code>search_in_maps_of_other_threads</code>.
</P>
<DT><B>23 Jan 2008</B>
<P class="news">libcwd-1.0.0 is released.&nbsp;
This version adds support for sparc64. All configure options now work also
on 64bit. Support for the latest SVN version of gcc (4.3) was updated.
</P>
<P class="news">An important bug has been fixed for the threaded case:
libcwd_r uses several pthread_mutexattr_t objects, but never initialized those.
This resulted in uninitialized memory being used resulting in random
mutex attributes. I believe this to be the reason that gcc-3.x locked
up on me. This version of gcc is therefore now supported again.</P>
<P class="news">Last but not least, as you see the version has been
bumped to 1.0.0! That means that the API is now holy. The SONAME
major version has been set to 1 (it was 99 before). I do not expect
this to change again (I will not change the existing API, or remove
interfaces-- not that this has happened in the past years anyway).
</P>
<DT><B>7 Jul 2007</B>
<P class="news">libcwd-0.99.47 is released.&nbsp;
This version adds support for x86_64. Yes, yes, I have a 64 bit machine
myself now, finally. It wasn't much work at all; so, to all those people
who have mailed me in the past about support for 64 bit: WHY DO YOU THINK
IT IS OPEN SOURCE?</P>
<DT><B>21 May 2007</B>
<P class="news">libcwd-0.99.46 is released.&nbsp;
A new configure option was added, <code>--enable-glibcxx-debug</code>,
that will cause libcwd to be compiled with
<a href="http://gcc.gnu.org/onlinedocs/libstdc++/debug.html">-D_GLIBCXX_DEBUG</a>.
When using magic numbers, but no redzone around allocations (the default),
the one to three bytes directly following the allocation till the next
alignment with a multiple of sizeof(size_t) were not checked. Thus,
a small overrun would not be detected in that case. This has been fixed.
Finally, this version was again updated to work with the current
SVN version of gcc (4.3).</P>
<DT><B>9 Nov 2006</B>
<P class="news">libcwd-0.99.45 is released.&nbsp;
This version works with gcc 4.2 (and the current 4.3 in SVN).
The library now works completely on Debian (I started to use debian myself).
Support for debug symbol packages (*-dbg on debian) was added: libcwd now
reads both, .debug/ and /usr/lib/debug/ debug files (as does gdb) when
the original library is stripped (it will not attempt to read them if
the original library still has a symbol table). libcwd's repository was
converted from CVS to SVN.</P>
<P class="news">Threading support with gcc versions 3.x has been dropped (use gcc 4.x).
It might work for you, or it might deadlock. Non-threading still
works fine with gcc 3.3 or higher.</P>
<P class="news">Support for libbfd (--enable-libbfd) has been completely
removed; I don't think anyone was using it anyway.</P>
<DT><B>23 May 2006</B>
<P class="news">libcwd-0.99.44 is released.&nbsp;
This release implements the possibility of 'redzones': you
can configure libcwd, using --with-redzone=x (in bytes), and it will
add (at least) x bytes above and below every allocation. See the NEWS
file in the release for more info. This has been quite a while in CVS,
now also released as tar ball.</P>
<P class="news">People who build libcwd from CVS (and therefore need to run autogen.sh)
be aware: my autoconf macros are now put in a separate project called
cwautomacros (I use them for multiple projects). You will need
to download and install cwautomacros before you can configure libcwd.</P>
<P class="news">Two bugs have been fixed: one that could cause a core dump during
global deinitialization (when the application terminates) and one
that could cause a COREDUMP for a self-"collision" of a shared
library at start up, namely when one tried to dlopen a library is
already linked to the application in the normal way.</P>
<DT><B>13 Dec 2005</B>
<P class="news">libcwd-0.99.43 is released.&nbsp;
This release fixes problems with the calculation of the load address
of shared libraries. On some systems, this bug resulted in not finding
a shared object for a given address, finding the wrong one, or even
core dumping on start up.
</P>
<DT><B>27 Nov 2005</B>
<P class="news">libcwd-0.99.42 is released.&nbsp;
Compiler warning fix for g++ 4.x in private_allocator.h.
</P>
<DT><B>26 Nov 2005</B>
<P class="news">libcwd-0.99.41 is released.&nbsp;
This release adds support for g++-4.0.2.&nbsp;
Addresses in libraries that are loaded on addresses lower than
the executable (yeah, I didn't know that was possible either) are now resolved.&nbsp;
dlopen/dlclose are now caught at link time
instead of #defining them, solving a bug that could cause a crash
when for example dumping memory allocations done in already dlclosed modules.&nbsp;
Finally, the .spec file was fixed so that
&apos;<code>rpmbuild&nbsp;-ta&nbsp;libcwd-0.99.41.tar.gz</code>&apos;
should work again on the latest Fedora release (that uses a new version of rpm).
</P>
<DT><B>31 May 2005</B>
<P class="news">libcwd-0.99.40 is released.&nbsp;
This release adds support for g++-4.0.0.
</P>
<DT><B>8 Oct 2004</B>
<P class="news">libcwd-0.99.39 is released.&nbsp;
This release fixes a few major bugs.&nbsp;
The most important one caused libcwd to crash even before reaching main
when the compiler used is configured with --enable-nls, making libcwd
completely useless on for example <A HREF="http://www.gentoo.org/">Gentoo</A>.&nbsp;
A second important bug that was fixed is one where the shared libraries
that one uses are stripped (as is also the case on Gentoo).&nbsp;
In this case libcwd failed to determine the end of a shared library
because the symbol "_end" is missing and it took the end of the <u>first</u>
function in the library by accident as end of the library, instead of
the last function.&nbsp;
As a result, addresses inside such stripped libraries could not be found
by libcwd - and worse, trying to print such locations caused a core dump!</P>
<P class="news">Special thanks go to Michal Grzejszczak for reporting the
problems with Gentoo; not many people take the effort to report bugs
these days, especially for a package that crashes immediately the first
time you try a 'Hello World'!  Thanks to him also Gentoo users can use libcwd
from now on.</p>
<DT><B>24 Sep 2004</B>
<P class="news">libcwd-0.99.38 is released.&nbsp;
This release adds support for gcc 3.4.2 (needed for the threaded case) and for
the latest gcc CVS version 4.0.0 (20040922).&nbsp;
The configuration option --disable-location has been fixed, and when using
this together with --disable-alloc you will now be able to use libcwd for
debug output on <U>cygwin</U> and <U>mingw32</U> (no threading yet).</P>
<P class="news">Along with a few other minor bugs, a rather nasty one that
appeared first on fedora core 2 machines have been fixed.&nbsp; If you have been
getting the following error when starting an application linked with libcwd:<BR>
<code>FATAL  : std::ifstream.open(""): ENOENT (No such file or directory)</code><BR>
Then you should certainly upgrade as this release will fix that.</P>
<DT><B>15 Jul 2004</B>
<P class="news">libcwd-0.99.37 is released.&nbsp;
This release concentrates on improving memory leak detection.&nbsp;
Unfortunately it had to contain again an API change: <code>ooam_filter_ct</code> has
been renamed to <code>alloc_filter_ct</code> and <code>ooam_format_t</code> has likewise
been renamed to <code>alloc_format_t</code>.</P>
<P class="news">With this release it is possible to filter the list
of printed allocations on <I>allocation-function</I> (the function from which
the allocation is done).&nbsp;
This makes it in principle possible to print a precise overview of leaked memory
at process termination by suppressing a list of "leaks" that are not really leaks.&nbsp;
Memory allocations now print the location where they are done at the moment they
are done - and not only when they are freed.&nbsp;
The memory allocation filter got a new flag <code>show_function</code> which causes
the mangled allocation-function to be shown (even when the sourcefile and line
number are known).&nbsp; I left this deliberately in mangled form because it
is more likely to be used in a regular expression search in your debug output
log file than to be understood by a human (and you can always use c++filt to
demangle it).&nbsp;
Finally, the function <code>list_allocations_on</code> now returns the number
of visible, non-filtered allocations; a value larger than 0 can then be
interpreted as 'memory leak'.&nbsp;
A pair of functions has been added to more easily control whether third-party
allocations are invisible or not: <code>libcwd::set_invisible_on</code> and
<code>libcwd::set_invisible_off</code>.&nbsp;
Memory allocated while this flag is set will be invisible and the <tt>MALLOC</tt>
showing the allocation will have '(invisible)' appended.&nbsp;
This line now also always shows the location where the allocator is called from.</P>
<P class="news">This release fixes the --disable-alloc configure flag and adds
support for gcc version 3.4.1 (needed for threaded applications).</P>
<DT><B>24 Jun 2004</B>
<P class="news">libcwd-0.99.36 is released.&nbsp;
A very minor bug fix release.</P>
<DT><B>23 Jun 2004</B>
<P class="news">libcwd-0.99.35 is released.&nbsp;
This release fixes a bug related to making memory allocations invisible.&nbsp;
Before it was not possible to make an allocation invisible that was allocated
with realloc(3) due to an assertion failure.&nbsp;
Library authors who use libcwd will need to carefully read the NEWS file
and <A href="reference-manual/group__chapter__custom__debug__h.html#libraries">The Custom debug.h File / Libraries</A>
paragraph in the reference manual, because the way that it has been set up has been changed.</P>
<DT><B>27 May 2004</B>
<P class="news">libcwd-0.99.34 is released.&nbsp;
Although this is mainly a bug fix release, it also contains a major API change:
the namespace <code>libcw::debug</code> was renamed to namespace <code>libcwd</code>.
Libcwd is now an official debian package and see, as a result I got some bug reports (finally!).&nbsp;
It turned out that libcwd had problems with certain shared libraries that use more than 256 entries
in the .debug_abbrev section.&nbsp; Finally, there turned out to exist two global initialization
order fiasco bugs for the non-threaded case; one showing on debian and one showing on gentoo.&nbsp;
All reported bugs have been fixed.</P>
<DT><B>23 Apr 2004</B>
<P class="news">libcwd-0.99.33 is released.&nbsp;
Added support for gcc version 3.4.0.  The latest gcc CVS version 3.5 is working again.&nbsp;
Two new features have been added:
<a href="reference-manual/group__chapter__gdb.html#a1"><CODE>debug_alloc(ptr)</CODE></a>
and <a href="reference-manual/group__chapter__gdb.html#a0"><CODE>debug_watch(ptr)</CODE></a>.&nbsp;
Both can only be called from within gdb.&nbsp; The first prints information about the memory
allocation (if any) under the pointer <code>ptr</code> and the second causes gdb to stop
as soon as the memory allocation under <code>ptr</code> is deleted or freed.</P>
<DT><B>22 Feb 2004</B>
<P class="news">libcwd-0.99.32 is released.&nbsp;
This release fixes a possible deadlock during initialization, in the threaded case.&nbsp;
The latest gcc CVS version 3.4 and 3.5 are working again.&nbsp;
Two new features have been added:
<a href="reference-manual/group__chapter__rcfile.html"><CODE>read_rcfile()</CODE></a>
and <a href="reference-manual/group__chapter__attach__gdb.html"><CODE>attach_gdb()</CODE></a>.&nbsp;
The first reads initialization from an rcfile (allowing to set which debug channels
should be on or off for example) and the second opens an xterm with an attached gdb session in it,
allowing you to start to debug the application from that point (especially handy for threaded
applications).</P>
<DT><B>28 Jun 2003</B>
<P class="news">libcwd-0.99.31 is released.&nbsp;
This release really works with glibc-2.3.2 and RedHat 9.&nbsp;
I missed the fact that RedHat 9 supports NPTL
(<A HREF="http://people.redhat.com/drepper/nptl-design.pdf">Native POSIX Threads Library</A>)
and TLS (<A HREF="http://people.redhat.com/drepper/tls.pdf">Thread Local Storage</A>)
(TLS needs at least g++ 3.3 or the version of 3.2.3 that comes with RedHat 9).&nbsp;
This release reimplements the way that libcwd deals with TSD (Thread Specific Data)
and now <EM>really</EM> works with NPTL.&nbsp;
Only the version of NPTL that comes with RedHat 9 was tested though (0.35, the current
<A HREF="http://people.redhat.com/drepper/nptl/">development version of NPTL</A> is 0.50).&nbsp;
You will need at least g++ 3.2.1 in order to get threading to work when you
have an NPTL enabled glibc, this is due to a bug in NPTL-0.35 but that bug
doesn't cause any problems with g++ 3.2.1 and higher.</P>
<DT><B>21 May 2003</B>
<P class="news">libcwd-0.99.30 is released.&nbsp;
This release works with glibc-2.3.2 and RedHat 9.&nbsp;
I found that the glibc that is distributed with rawhide is broken.
A few threads related bug have been fixed among which a serious one
that caused allocations done between two <CODE>list_allocations_on()</CODE>'s
using the same filter (or none at all, which uses the default filter) to be
randomly filtered (depending on an uninitialized boolean).</P>
<DT><B>3 May 2003</B>
<P class="news">libcwd-0.99.29 is released.&nbsp;
This release contains a few large changes.&nbsp;
All the header files have been moved from <CODE>libcw/</CODE> to <CODE>libcwd/</CODE>.&nbsp;
Compiler version 3.x is now required (2.95 and 2.96 didn't support stringbuffers
well enough).&nbsp;
All allocations inside <CODE>Dout()</CODE> et al are now non-internal!&nbsp;
Finally there were a few minor bug fixes.&nbsp;
Please read the <CODE>NEWS</CODE> file as usual, for more details.</P>
<DT><B>12 February 2003</B>
<P class="news">libcwd-0.99.28 is released.&nbsp;
This release adds support for <CODE>new(std::size_t, std::nothrow_t const&amp;)</CODE>
allowing it to be used with gtkmm-2.0 among others.&nbsp;
The demangler was fixed to match the mangling of g++ 3.1, which uses a slightly
different way to mangle constant member functions than g++ 3.0 did.&nbsp;
The decoding of line numbers has once again been improved and is now perfect
(assuming you don't use a compiler that generates broken debug information).&nbsp;
Finally, this release fixes a bug where dlopen() could only read
libraries with an absolute path, failing for libraries that
reside somewhere in <CODE>LD_LIBRARY_PATH</CODE>.</P>
<DT><B>16 November 2002</B>
<P class="news">libcwd-0.99.27 is released.&nbsp;
This release fixes a few minor bugs.  Well, minor unless you run into them of course: libcwd would core dump
when reading a shared library whose last compilation unit did not contain a .debug_line section.
And linking with a libcwd that was configured with --disable-alloc would lead to an undefined reference.
Finally, demangling of _GLOBAL_* functions have been fixed.</P>
<DT><B>13 September 2002</B>
<P class="news">libcwd-0.99.26 is released.&nbsp;
This release contains some bug fixes and a new 'overview of allocated memory' filter class extension:
<CODE STYLE="font-size: smaller">ooam_filter_ct::hide_unknown_locations(bool)</CODE>.</P>
<DT><B>5 September 2002</B>
<P class="news">libcwd-0.99.25 is released.&nbsp;
This release fixes a few major bugs: internal memory leaks in libcwd
itself (now garanteed leak free!), and the demangle routines weren't
thread safe when you were using compiler version 2.95.x or 2.96.&nbsp;
Also, the library was erroneously not compiled with -O, making it
about twice as slow (still very fast).&nbsp;
The function <CODE>list_allocations_on()</CODE> didn't work at all for 
other debug objects; only <CODE>list_allocations_on(libcw_do)</CODE> would work.&nbsp;
Under certain circumstances (linking with a third party C++ library
that got initialized first and whose first allocation is via
std::allocator) would lead to a dead lock during initialization.&nbsp;
Finally, <CODE>channel_ct::get_label()</CODE> has been changed to be zero
terminated.&nbsp; The fact that it was not (deliberately), wasn't very
clearly documented.</P>
<DT><B>19 August 2002</B>
<P class="news">libcwd-0.99.24 is released.&nbsp;
This release fixes multi-threading problems among which writing continued
debug output: the label of each output line will now really always start
on a new line.</P>
<DT><B>18 July 2002</B>
<P class="news">Today an excellent <a href="http://www.kuro5hin.org/story/2002/7/18/3313/01429">review</a> of C++ tools appeared on the front page of 
<a href="http://www.kuro5hin.org/">kuro5hin.org</a> in which libcwd
received positive critics.</P>
<DT><B>17 July 2002</B>
<P class="news">libcwd-0.99.23 is released.&nbsp;
This release adds two possibilities to the 'overview of allocated memory' filter class:
<CODE STYLE="font-size: smaller">ooam_filter_ct::hide_sourcefiles_matching(std::vector&lt;std::string&gt;&nbsp;const&amp;)</CODE>
and <CODE STYLE="font-size: smaller">ooam_filter_ct::hide_untagged_allocations(bool)</CODE>.<BR>
You now can pass a filter to a <CODE>marker_ct</CODE> to
specify which allocations are to be considered outside the marker
area as well as how to list the allocations that were leaked.&nbsp;
Three minor bugs have been fixed: two related to the use
of dlclose() and one that caused the full path of location source
files to be incomplete when using gcc 3.x.</P>
<DT><B>21 June 2002</B>
<P class="news">libcwd-0.99.22 is released.&nbsp;
Fixes a horrible bug that was introduced in 0.99.20, causing
any realloc() to crash when not having used an AllocTag for it.&nbsp;
Did not run into this before because all of the testsuite uses
AllocTag for reallocated blocks, and libstdc++ doesn't use realloc
at all.&nbsp;
I now ran into it because I am playing with libgtkmm.</P>
<DT><B>18 June 2002</B>
<P class="news">libcwd-0.99.21 is released.&nbsp;
This release adds support for g++ 3.1.&nbsp;
In the previous two versions there was an include missing
causing libcwd not to compile on SuSe and Mandrake.&nbsp;
The administration of allocated memory is now kept
in an STL map <EM>per</EM> thread instead of one big global map.&nbsp;
The advantage of that is that in general a
call to new/malloc etc. will not cause a thread to
have to wait for other threads anymore.</P>
<DT><B>24 May 2002</B>
<P class="news">libcwd-0.99.20 is released.&nbsp;
This release fixes three (possible) deadlocks in <CODE>list_allocations_on</CODE>,
one in <CODE>dlopen</CODE> (when an error occured during loading),
and one during core dumping (<CODE>COREDUMP</CODE>) in
<CODE>pthread_kill_other_threads_np</CODE>.&nbsp;
Furthermore a bug was fixed in relation to the use of the control flag
<CODE>error_cf</CODE> as that was using the non-reentrant
libc function <CODE>strerror</CODE> instead of
<CODE>strerror_r</CODE>, causing libcwd likely to complain
about freeing an 'internal' allocation (which means that the user (or the
system) is freeing memory that was allocated by libcwd, and libcwd likes
to take care of its own allocations).</P>
<P class="news">Support for non-threaded applications on solaris 2.8 has been added as well.&nbsp;
Please contact me if you are interested in making threads work too on this OS.&nbsp;
The same holds for FreeBSD.</P>
<DT><B>23 April 2002</B>
<P class="news">libcwd-0.99.19 is released.&nbsp;
This release fixes a deadlock during the initialization of threaded applications
that use g++ version 2.96 or earlier.  There are now two libraries compiled
and installed: a thread safe version which is called libcwd_r, and the thread
unsafe version called libcwd.  Finally, a new feature is added that allows
one to filter the overview of allocated memory, removing the output related
to certain shared libraries; restricting the memory allocations shown to a
given time interval in which they were allocated; and showing the full path
of a location source file at which the allocation took place, the time at
which the allocation was made and/or the name of the shared library an allocation
belongs to.  Detailed information can be found in the <a href="reference-manual/group__group__alloc__format.html">reference manual</a>.</P>
<DT><B>11 March 2002</B>
<P class="news">libcwd-0.99.18 is released.&nbsp;
This release contains several minor documentation fixes and again an API change: the
configure option related macros (<CODE>DEBUGMALLOC, DEBUGDEBUG</CODE> etc) have been
renamed and are defined to 0 or 1 instead of being undefined or defined.&nbsp;
As always, read the NEWS file!</P>
<DT><B>10 March 2002</B>
<P class="news">A project has been created on <a href="http://sourceforge.net/projects/libcwd/">sourceforge</a>
especially for libcwd.&nbsp;
This means that libcwd also has a new home page now (you're probably looking at it):
<a href="http://libcwd.sourceforge.net/">http://libcwd.sourceforge.net/</a>.<br>
<b>Bookmark this page!</b></P>
<DT><B>18 February 2002</B>
<P class="news">libcwd-0.99.17 is released.&nbsp;
This release fixes a few bugs related to threading.&nbsp;
Also a few typos in the tutorial have been fixed and a new chapter
on debugging threaded applications was added.</P>
<P class="news">Errata: There is a typo in the documentation.&nbsp;
The environment variable isn't <SPAN class="code">LIBCWD_ALWAYS_PRINT_LOADING</SPAN>
but <SPAN class="code">LIBCWD_PRINT_LOADING</SPAN>.</P>
<DT><B>13 February 2002</B>
<P class="news">libcwd-0.99.16 is released.&nbsp;
Five months of non-stop, hard work, but here it finally is: libcwd is now thread-safe!&nbsp;
In order to get a thread-safe version you have to use the configuration option
<SPAN class="code">--enable-libcwd-threading</SPAN>.&nbsp;
This release also contains new documentation that was generated with
<a href="http://www.doxygen.org">doxygen</A>; no more slow on-line browsing,
now you can read the reference manual locally.</P>
<P class="news">There are a few major API changes again (I know, I know - but if you don't
like it then wait till release 1.0).&nbsp;
If you are upgrading from a previous version:
<b>Read the NEWS file that comes with the source distribution</b>
for details about these API changes!&nbsp;</P>
<DT><B>22 September 2001</B>
<P class="news">libcwd-0.99.15 is released.&nbsp;
This release contains one API change: you now <EM>must</EM> define <SPAN class="code">CWDEBUG</SPAN> when compiling.&nbsp;
Using <SPAN class="code">-DDEBUG</SPAN> will not work any longer.&nbsp;
A few major bugs have been fixed in this release.  Two demangle bugs, a bug related to symbol
name lookup and a compilation error (gcc-3.0 couldn't find the header file <SPAN class="filename">gthr-default.h</SPAN>,
which is actually a bug in the header files of the compiler).&nbsp;
A bug in the demangler for gcc-2.96 and earlier caused core dumps for symbols that
started with <SPAN class="code">_X...</SPAN>.&nbsp; Since those are used a lot in
X libs, libcwd was unusable with X windowing system applications (like those using qt).&nbsp;
This version of libcwd has been tested (for the first time) with a single threaded
qt application.&nbsp; Another major problem was an erronous assertion in the ELF
symbol lookup code that failed on glibc-2.2.4, making libcwd unusable with that version.
</P>
<DT><B>28 August 2001</B>
<P class="news">libcwd-0.99.14 is released.&nbsp;
Nobody did notice it (nobody mailed me about it), but under certain circumstances the previous version could
horribly fail in determining the correct line number of a location.&nbsp; This version should fix that!&nbsp;
There is more news however, we have a new developer for libcwd!&nbsp; Eric is an experienced coder who I've
known for about eight months now (on our IRC channel #g++ on Undernet).&nbsp; I've already been enjoying many
fruitful discussions with him before, and now he joined the coding forces in order to attack the thread-safety
problem.&nbsp; We're hoping to make libcwd thread-safe in the foreseeable future.&nbsp; In the meantime you
can see what we're doing using CVS and the unstable alpha branch:<SPAN class="code"> branch-threading</SPAN>.</P>
<DT><B>20 August 2001</B>
<P class="news">libcwd-0.99.13 is released.&nbsp;
New in this release is support for dynamically loaded shared object files (<SPAN class="code">dlopen()</SPAN>).&nbsp;
Also new is native support for the DWARF 2 debug format (this is used when you compile with <SPAN class="code">-ggdb</SPAN>
or <SPAN class="code">-gdwarf-2</SPAN>.&nbsp;
It is also used for <SPAN class="code">-g</SPAN> when DWARF is the native debug format, as is the case on IRIX 6).&nbsp;
The advantage of DWARF is that it is much faster to load: it is very compact and stores the line number information
in a seperate section so that we don't have to load other debug info.&nbsp;
In the case of stabs (the native debug format of linux) we need to load <EM>all</EM> debug information.&nbsp;
You'll notice that libcwd now prints "Loading debug info from ..." under all circumstances when an application is started.&nbsp;
It uses debug channel <SPAN class="code">dc::bfd</SPAN> and in most cases <EM>before</EM> <SPAN class="code">main()</SPAN>
is reached.&nbsp; This is achieved by forcing the debug object as well as <SPAN class="code">dc::bfd</SPAN> to <EM>on</EM>
prior to loading the debug information from the object files.&nbsp; This was disabled in previous versions because it's a bit
tricky: at this point the debug object might not be initialized yet!&nbsp; Previously, only a snap shot version of g++ that
I kept around caused a crash because of this (it depends highly on the order in which global objects are initialized), but now
I made a few changes that make me feel confident enough to enable it by default.&nbsp; If you still get a crash, or if you want
to disable this printing for other reasons, then you can <SPAN class="code">#undef ALWAYS_PRINT_LOADING</SPAN> in
<SPAN class="code">src/libcwd/bfd.cc</SPAN>.</P>
<P class="news">This release contains <B>two API changes</B> - and rather annoying ones I am afraid:
Firstly, the header file <SPAN class="code">&lt;sys.h&gt;</SPAN> has been renamed to <SPAN class="code">&lt;sysd.h&gt;</SPAN>.&nbsp;
Please manually remove the old <SPAN class="code">&lt;sys.h&gt;</SPAN> if you install libcwd over an old install: that is the
only way to be sure that you are not accidently including it somewhere.&nbsp;
Secondly, the debug channel <SPAN class="code">dc::warning</SPAN> is turned on by default - which will cause a core dump
if you try to turn it on yourself at the start of <SPAN class="code">main()</SPAN>: You have to remove an explicit
<SPAN class="code">Debug(&nbsp;dc::warning.on()&nbsp;)</SPAN> if you have one.</P>
<DT><B>1 August 2001</B>
<P class="news">libcwd-0.99.12 is released.&nbsp;
This release fixes the bug that libcwd was accessing recently freed memory.&nbsp;
In all that time this never lead to a crash for me, amazing.</P>
<DT><B>31 July 2001</B>
<P class="news">libcwd-0.99.11 is released.&nbsp;
Debug channel <SPAN class="code">dc::stabs</SPAN> was renamed <EM>back</EM> to
<SPAN class="code">dc::bfd</SPAN>.&nbsp; Possible confusion was now solved
differently by renaming the configure option <SPAN class="code">--enable-libcwd-bfd</SPAN>
into <SPAN class="code">--enable-libcwd-libbfd</SPAN>.</P>
<DT><B>31 July 2001</B>
<P class="news">libcwd-0.99.10 is released.&nbsp;
This release comes with two major changes.&nbsp; <SPAN class="code">malloc(3)</SPAN> and friends are now
exported with external "C" linkage instead of being a macro; this means that also allocations done from
other shared libraries like libc are caught now.&nbsp; Most notably, this fixes the bug that
<SPAN class="code">strdup(3)</SPAN> couldn't be used (thanks for the feedback I now got!).&nbsp;
This release doesn't depend anymore on GNU's <SPAN class="code">libbfd</SPAN>; it is now capable of understanding stabs debug
info read from ELF32 object files directly.&nbsp; You will need to use the configure option <SPAN class="code">--enable-libcwd-bfd</SPAN>
to get the old behaviour back and still link with <SPAN class="code">libbfd</SPAN>.&nbsp; Note that due to the viral nature
of the GPL (that doesn't allow one to link a program with a GPL-ed library and then distribute it under
any other license but the GPL (unlike the LGPL and QPL)), you are not allowed to <EM>distribute</EM> executables
that are linked against <SPAN class="code">libbfd</SPAN> because you could only do so under the GPL and that violates the license of libcwd (QPL).&nbsp;
I trust that this is not a problem as these are purely test-executables.</P>
<DT><B>9 July 2001</B>
<P class="news">libcwd-0.99.9 is released.&nbsp;
This release comes with a brand new demangler for the new C++ ABI as promised.&nbsp;
I am happy to have learned that there exists interest in libcwd in the Open Source community: the maintainer
of gdb wrote me that he translated the new demangler into C and will incorporate it into GNU libiberty
and gdb (the current demangler in libiberty doesn't handle qualifiers correctly in all cases).&nbsp;
The maintainer of clisp expressed his interest in the bfd.cc file in order to be able to print
backtraces in case of internal errors.</P>
<P class="news">I have very little feedback from users of libcwd itself though.&nbsp;
If there is anything you would like to be added, or when you find a bug, <B>mail me</B>.&nbsp;
<EM>It won't get fixed when you don't tell me about it!</EM>&nbsp;
But if you are just a happy user without any complaint, I'd really love to hear from you too!
Click <A HREF="http://www.xs4all.nl/~carlo17/anti/spam/bots/dont/like/deep/dirs/mail2.html?libcwd">here</A> and drop me mail!</P>
<DT><B>29 May 2001</B>
<P class="news">libcwd-0.99.8 is released.&nbsp;
Finally, after a long delay a new release - and as promised one that works with libstdc++ version 3!
This release still lacks a demangler for the new C++ ABI however (that is part of g++-2.97 and higher), which
will be added to the next release.</P>
<P class="news">Making libcwd suitable for libstdc++-v3 wasn't an easy task.&nbsp; One of the major problems is
that during the writing of debug output (for example <SPAN class="code">operator&lt;&lt;(ostream&, int)</SPAN>)
memory is being allocated under certain circumstances by libstdc++-v3.&nbsp; While it is unacceptable that
due to writing debug output other debug output is generated, there were only two options: 1) turning off
the <SPAN class="code">malloc</SPAN> and <SPAN class="code">bfd</SPAN> debug channels but still storing all
memory allocations in memory allocation overview, or 2) making all memory allocations done from a
<SPAN class="code">Dout</SPAN> <I>internal</I>, disabling any checks.&nbsp; With in mind that the existance of
debug code shouldn't matter (after all, it won't be in the final production version of an application) it follows
that no memory should be allocated in the first place as part of a <SPAN class="code">Dout</SPAN>
and when it <EM>is</EM> it isn't important if it leaks or not - I decided to go for solution two because that
uses less cpu.</P>
<P class="news">Other changes involve mostly a rewrite of certain parts that were depending on a specific GNU implementation
of libstdc++, using the now available standard.&nbsp;
While most of these changes are invisible, there was a small change to the interface of <A HREF="bfd.html#type_info_of"><SPAN class="code">type_info_of</SPAN></A>
resulting at the same time in preserving a top-level <SPAN class="code">const</SPAN> qualifier as well as faster code
(with g++-3.0 that is; older versions of g++ are still so much broken that slower work-arounds were needed).&nbsp;
The only kludge left in libcwd at the moment is the detection of when the standard streams are initialized.&nbsp; I blame the need
for this kludge on a bug in libstdc++-v3 and have reported it as such; perhaps also this can be gotten rid of in the
future.</P>
<P class="news">At the moment of writing two problems are already known with 0.99.8:</P>
<P class="news">Using a libbfd on a 32bit machine
that was compiled with 64bit target support will fail to work with libstdc++-v3 when the latter is compiled without
support for <SPAN class="code">long long</SPAN> (<SPAN class="code">long long</SPAN> is <EM>not</EM> a part of the
C++ standard, while it <EM>is</EM> part of C99.&nbsp; libbfd being a C library, this results in problems).&nbsp; I added
a test for this to 0.99.8 but accidently forgot to test for libstdc++-v3 causing libcwd to fail always with g++-2.95.x!
If you get this error:
<I>libbfd is compiled with 64bit support on a 32bit host, but your libstdc++ is not compiled with support for long long.</I>
and you are using g++-2.95.x then just remove the <SPAN class="code">#error</SPAN> line from bfd.cc and it should compile just fine.</P>
<P class="news">Finally, it is known that many operating systems can't deal with shared C++ libraries and global objects.&nbsp; While this
means that those operating systems are broken, I decided to fix this problem by removing all global objects in the next
release.&nbsp; So, if libcwd core dumps on you for even very simple programs then please try 0.99.9 when it gets released.</P>
<DT><B>2 March 2001</B>
<P class="news">libcwd-0.99.7 is released.&nbsp;
This release includes a work-around for the compiler crash in <SPAN class="filename">lockable_auto_ptr.h</SPAN>
that occured with g++-2.95.x.&nbsp;
There are a few other changes however; most notably, the support for the macro <SPAN class="code">Dout_vform</SPAN>
has been removed because <SPAN class="code">ostream::vform</SPAN> isn't conforming to the Standard and is gone in
libstdc++ version 3.&nbsp;
Note that this release still doesn't work with libstdc++ version 3, hopefully the next release will.</P>
<DT><B>10 February 2001</B>
<P class="news">libcwd-0.99.6 is released.&nbsp;
This release deals with namespace issues and therefore contains a few major API changes.&nbsp; 
The most important changes follow.&nbsp; The macro DEBUG has been renamed to CWDEBUG because
the former was too general and collided with other libraries.&nbsp;
All functions have been moved to namespace <SPAN class="code">libcwd</SPAN>;
this will break compilation of programs that use earlier versions of libcwd,
unless one includes a &quot;<SPAN class="code">using namespace libcwd;</SPAN>&quot;
line in the source files using more than just <SPAN class="code">Dout</SPAN> and
<SPAN class="code">Debug</SPAN>.&nbsp;
Four functions have not only been moved to the new namespace but were also renamed.&nbsp;
Apart from this all, also the interface to BFD has been redesigned; among others the
structure <SPAN class="code">location_st</SPAN> has been replaced by a class <SPAN class="code">location_ct</SPAN>.&nbsp; Also here
functions have been renamed or even removed.&nbsp;
<EM>Please read the <B>NEWS</B> file contained in the source distribution for details.</EM>&nbsp;
A new template function has been added: <SPAN class="code">cwprint_using</SPAN>.&nbsp;
This utility allows one to easily print objects using a method of the object rather
than <SPAN class="code">operator&lt;&lt;</SPAN>.&nbsp; Finally, two bugs have been
fixed: one in the demangler which still couldn't demangle const member functions, and
a bug that could cause a core dump when memory was allocated from the constructor of
a global object that was initialized before libcwd was initialized, this has only been
reported for solaris.</P>
<DT><B>29 January 2001</B>
<P class="news">libcwd-0.99.5 is released.&nbsp;
This release contains mostly bug fixes, especially for the demangler.&nbsp;
Otherwise it mainly contains support for the compiler that is released with
RedHat-7.0: gcc-2.96.&nbsp;
Version 0.99.5 contains two API changes: the prototype of <SPAN class="code">libcw_bfd_pc_location</SPAN>
was changed in order to get rid of the <EM>named return values</EM> gcc extension that has been
deprecated in g++-2.96 and higher.&nbsp;
Secondly, <SPAN class="code">DoutFatal</SPAN> doesn't have a default
debug channel anymore and <SPAN class="code">dc::fatal</SPAN>,
which was the default in prior releases, must explicitly be specified.</P>
<DT><B>11 October 2000</B>
<P class="news">libcwd-0.99.4 is released.&nbsp;
This release comes with a testsuite and again allows Linux users to
just link their application with <SPAN class="code">-lcwd</SPAN>
(without the need to also specify <SPAN class="code">-lbfd -liberty</SPAN>).&nbsp;
All reported bugs (two) have been fixed, as well as a third that showed
up while I wrote the testsuite: a locked <SPAN class="code">lockable_auto_ptr</SPAN>
does <EM>not</EM> transfer ownership anymore when using the assignment operator.</P>
<DT><B>13 September 2000</B>
<P class="news">libcwd-0.99.3 is released.&nbsp;
This release includes an example showing how to use libcwd in
an <SPAN class="filename"><A HREF="http://sources.redhat.com/autoconf/">autoconf</A></SPAN>/<SPAN class="filename"><A HREF="http://sources.redhat.com/automake/">automake</A></SPAN> project.&nbsp;
<STRONG>Please note</STRONG> that, due to constraints of libtool, your programs need to be linked with
<SPAN class="code">-lcwd -lbfd -liberty</SPAN> now (as opposed to just <SPAN class="code">-lcwd</SPAN>).&nbsp;
Support for Solaris has been added.&nbsp;
The autoconf/automake configuration setup has been improved;
also the configuration on FreeBSD should work out of the box now (assuming you have binutils installed).&nbsp;
Finally, a <SPAN class="filename">.spec</SPAN> file for building an RPM has been added to this release.</P>
<DT><B>29 August 2000</B>
<P class="news">libcwd-0.99.2 is released.&nbsp; Added autoconf/automake/libtool for configuration.&nbsp;
This obsoletes the need for the <A HREF="http://www.xs4all.nl/~carlo17/prototype/index.html">prototype</A> package.&nbsp;
The source file <span class=filename>demangle.cc</span> was completely rewritten and now supports demangling of
<A HREF="bfd.html#demangle">symbols</A> as well as types.</P>
<DT><B>15 August 2000</B>
<P class="news">libcwd-0.99.1 is released.&nbsp; Apart from a few minor bug fixes, support for FreeBSD has been added!</P>
<DT><B>08 August 2000</B>
<P class="news">The web site has been improved in order to give new visitors a quicker overview:
libcwd now has its own home page.&nbsp; A page with features and "screenshots" was added.</P>
<DT><B>04 August 2000</B>
<P class="news">First public announcement of libcwd on freshmeat.</P>
<DT><B>23 July 2000</B>
<P class="news">First public release of libcwd on sourceforge.</P>
</td></tr></table>

</td></tr></TABLE>

</TD></TR><TR><TD>
&nbsp;
</TD></TR>
</TABLE>

<BR>
<HR SIZE=1 NOSHADE>
<TABLE BORDER=0><TR>
<TD VALIGN=top><A class="image-link" href="http://sourceforge.net"><IMG width="88" height="31" src="images/sflogo.png" border="0"></A></TD>
<TD VALIGN=top><A class="image-link" href="http://www.w3.org/Style/CSS/Buttons" target="_blank"><IMG width=88 height=31 src="images/css.gif" border=0 alt="Cascading Style Sheets" align=top></A></TD>
<TD VALIGN=bottom width=0><A class="image-link" href="http://sourceforge.net"><IMG width="1" height="1" src="http://sourceforge.net/sflogo.php?group_id=47536&amp;type=5" border="0"></A></TD>
</TR></TABLE>

</BODY>
</HTML>