-
Notifications
You must be signed in to change notification settings - Fork 4
/
Copy pathNEWS
1870 lines (1481 loc) · 75 KB
/
NEWS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
libcwd-1.1.3
Fixed a stack overflow issue for large PID's. Now
a PID can be as large as max int.
Added support for color escape codes to give every
thread a different color.
Handle empty address ranges gracefully. This fixes a possible
Assertion `start != 0 && end > start' failed
libcwd-1.1.2
Added support for cmake.
Fixed a bug in reading DWARF 4 debug information.
libcwd-1.1.1
Added support for aligned_alloc(3).
Fixed address/location lookup for PIE executables.
libcwd-1.1.0
All occurances of 'trylock' have been renamed to 'try_lock'.
This breaks interface API backwards compatibility, but it
allows one to use std::mutex for debug_ct::set_ostream.
libcwd-1.0.7
Started using (the new) cwm4 git module for configuration;
that means that cwautomacros isn't needed anymore when
checking libcwd out from git.
libcwd-1.0.6
Support for g++ 6.x, 5.x and DWARF version 4.
Added channel_ct::operator(bool)
This allows one to turn off debug output for a channel that is on
on a per invocation basis by doing:
Dout(dc::notice(cond), ...);
which then will only print debug output if 'cond' is true (and
dc::notice is on).
Added libcwd/cwlist.h to libcwd - this isn't used by
libcwd itself, it's just an extra gadget for you.
Bug fixes:
Reallocating a memory block that was originally allocated
in a different thread could lead to undefined behavior (when
memory allocation checking is on, which is the default).
libcwd-1.0.4
Support for libc-2.10.
Bug fixes:
Some obscure bug with the internal rwlock_tct.
libcwd-1.0.3
Undocumented support for a 'backtrace_hook' function. The hook is
called (if set) whenever memory is allocated, passing the current
backtrace.
Bug fixes:
Patch by Joel Nordell to avoid a stack overflow in ~dm_alloc_copy_ct()
in the case that all M_next objects in the chain is a very long list.
Fixed a bug that could crash while accessing a (deleted) memblk_map_ct.
libcwd-1.0.0
Fixed problems that stopped libcwd from working on sparc64.
Thanks to Dennis Gilmore for giving me an account on his sparc64.
Bug fixes:
pthread_mutexattr_t objects were not initialized, resulting
in undefined behaviour (libcwd_r only). I think this is what
caused my previous problems with gcc-3.3.x. So, that version
is supported again (this version of libcwd is tested to work
again with 3.3.6).
Fixed parallel build; make -j N now works.
Fixed --disable-pch and --disable-alloc (broken since 0.99.47).
Fixed --enable-debugt on amd64.
libcwd-0.99.47
Added support for x86_64 / ELF64.
libcwd-0.99.46
Libcwd now can be compiled with -D_GLIBCXX_DEBUG by passing
--enable-glibcxx-debug during configuration.
Bug fixes:
When not using redzones (though still using magic numbers around
allocations of course), allocation of not a multiple times
sizeof(size_t) lacked the overflow test for the few bytes needed
to align again to a mutliple of size_t. For example, if you'd
allocate 9 bytes, then bytes 10, 11 and 12 were not checked for
an overflow.
libcwd-0.99.45
Support for libbfd (--enable-libbfd) has been entirely
removed. There is a problem with the initialization;
libcwd code is executed very early, before libbfd is
initialized. The call to bfd_openr returns an
uninitialized bfd structure...
Debug symbols are now read from .debug/ or /usr/lib/debug
when it is found that the real library is stripped.
The CVS repository was converted to SVN. See README.SVN
on how to get the latest alpha release.
Bug fixes:
Several compile bug fixes for FreeBSD.
--disable-location was fixed.
Libcwd would segfault if the application is linked with
with -ldl left of -lcwd because then it can't find the
correct dlopen (with dlsym(RTLD_NEXT, "dlopen")). Now it
prints an error message about this and aborts.
Several debian specific problems have been fixed (I am
using debian myself now).
libcwd-0.99.44
Allocated memory (operator new/new[], malloc/calloc/realloc)
now can be extended with 'redzones'. The foot print of
allocated memory will look as follows:
pointer returned --> +------------------------+
by libc's malloc | magic number |
+------------------------+
| size |
+------------------------+
| |
| RED ZONE |
| |
pointer returned --> +------------------------+
to the application | |
| Application space |
~ ~
| |
+------------------------+
| |
| RED ZONE |
| |
+------------------------+
| magic number |
|________________________|
The 'size' is the size of the application space
(the requested space), incremented by a few bytes,
if necessary, to align it to a multiple times size_t,
and then increment that same amount again (not
that you're supposed to access that value anyway).
'size' and 'magic number' are size_t. The first red
zone has a size such that the the difference between
the pointer returned by libc's malloc and the pointer
returned to the application is a multiple times 8
bytes (the alignment garanteed by glibc's malloc).
The redzone at the end has the same size incremented
by a few bytes, if necessary, to align the last magic
number to a sizeof(size_t) boundary. The pre- and post-
redzones are filled with two different characters.
At the moment a memory block is freed, these values
are tested.
You can chose the size of the redzone (default is 0)
with the configure option --with-redzone=x in bytes.
The real size will likely be larger because of the
alignment constrains.
Libcwd now uses cwautomacros: in order to build it
from CVS you need to download and install cwautomacros
from http://cwautomacros.berlios.de/
Bug fixes:
BlockList::uninitialize() accessed a struct that it just
deleted, with a possible core dump as result. Fortunately,
this bug wasn't too serious, because this function is
only called as part of the global deinitialization
of the application, after leaving main or calling exit.
Calling dlopen for a library that is already linked
the normal way would terminate the program (thinking
two different shared libraries overlapped). Libcwd
now properly 'ignores' such load attempts.
libcwd-0.99.43
Bug fixes:
It was still possible that unnamed 'shared libraries' that are
mapped and listed in the dl_loaded list caused libcwd to crash
with the error:
FATAL : std::ifstream.open(""): ENOENT (No such file or directory)
I thought this was fixed in 0.99.38, but there was another place
in the source where a test for this case was needed.
Several serious bugs have been fixed related to the calculation
of the load address of a shared library. A problem was that
a load address returned by the dynamic linker of zero was
treated as 'unknown' (falling back to more heuristic methods
in that case). However, it turns out that on some machines,
sometimes, system libraries are loaded "at" address 0. Avoiding
overlaps between libraries in this case is done by having
some 'empty' section at the beginning of the shared object
that gives the library it's required offset, instead of loading
each library at a different address (this only works when
all those libraries have such empty sections that are 'tuned'
in size to be compatible with one another). Apparently, this
only works as a 'hint' for the dynamic linker, because it can
still put the real image somewhere else in memory, possibly even
with a negative 'load address'. This method was so different
from how it worked on my system that libcwd totally messed up.
On top of that, libcwd used the FILE offset to calculate the
start of a section in memory, instead of the 'memory image'
offset of the section (the VMA). That worked on my machine
because all executable sections are at the start of the the
shared library, so that the vma and the file offset were
equal (with the exception of the executable, but libcwd made
a special exception for that case). Blame this on the extremely
bad availability of documentation on how dynamic linkers work.
Anyway, thanks to an american soldier, who let me login on
his laptop, via an ppp-over-ssh tunnel to get around the
firewall for their army base in Irak (how exciting, and all
that via a satelite link into the desert, of course), I've
been finally able to debug on a machine that used this different
way of linking and finally understand what VMA really is ;).
Note that this also means that there is a huge difference
between the load address of a shared library and the first
(lowest) address that can actually be part of executable
code of that library, something that was already fixed for
the executable on 0.99.41 -- now also for all other shared
objects.
There was a missing colon between the mangled function name
and the demangled function name (using a filter that printed
both) in the allocated memory overview.
Libcwd's new allocator got a face lift. It had some problems
with large numbers of requested chunks due to two linear list
searches over allocated memory blocks (even though each block
is 8192 bytes, in some cases several thousand blocks are needed,
making those linear searches rather slow). The current
implementation is even faster than the allocator of libstdc++
(constant allocation and deallocation times for any ammount
allocated chunks).
libcwd-0.99.42
Bug fixes:
Compile warning for unused 'a1' and 'a2' in private_allocator.h
was fixed (only needed for g++-4.x).
libcwd-0.99.41
Bug fixes:
Although the 'load address', relative to which ELF32 symbols
are given, is 0 for the main executable, it doesn't have to
be the REAL load address. It turned out that it is possible
that shared libraries are loaded into memory BELOW the
executable. This resulted in a problem when the executable
dynamically loads a library in this low region: a symbol
look up for shared libraries that are loaded later was thought
to be part of the executable and not resolved correctly.
The 'start' of the executable is now set to be the start
address of the first function, instead of 0.
The trick of #defining dlopen and dlclose in order to catch
calls to them simply doesn't work. A better method is being
used now that actually catches all calls to dlopen/dlclose.
This also allowed to reliably reset type_info pointers in the
alloc_ct of allocations done from a loaded module that used
AllocTag and is leaking that memory. Before, an application
would core dump when dumping (apparently leaking) allocations
done in a module that was dlclosed already and for which
AllocTag was used, because the static type info object is
part of the shared object which was unloaded, leading to
reading invalid memory.
As of g++-4.0.2 yet ANOTHER mt_alloc implementation was released
with the gcc compiler. This time making it near impossible to
use it. Getting really tired of this, libcwd now comes with it's
own allocator, so that this upgrade problem has been solved once
and for all. The new allocator is used with gcc-4.0.0 and higher.
libcwd-0.99.40
Bug fixes:
libcwd didn't compile with the g++ 4.0.0 that was actually
released.
libcwd-0.99.39
Updated support for g++ 4.0.0.
The gdb functions debug_alloc and debug_watch have been
renamed to cwdebug_alloc and cwdebug_watch respectively
because they could no longer be static (gdb didn't see
them anymore) and otherwise would polute namespace too
much.
Bug fixes:
debug_ct::push_marker was broken. It left allocations
at 'internal' causing fatal error messages in a subsequent
delete or free about the attempt to delete a non-internal
memory allocation with memory allocation checking off.
The size of stripped shared libraries was incorrectly
determined (the end of the library was set to the end
of the first function in the library instead of the last).
As a result, addresses in such libraries resulted in
not being able to lookup the correct shared object file.
Moreover, printing a location_ct with such an unknown
object file would core dump.
The creation of a std::ios_base::Init does still allocate
memory with g++ 3.3 and higher if that compiler is
configured with --enable-nls, as is the case for Gentoo.
As a result, libcwd - that assumes no memory was allocated
anymore as of 3.3 - would core dump even before reaching
main.
libcwd-0.99.38
Added support for g++ 3.4.2 and 4.0.0.
Configuration with --disable-location has been fixed and
is now supported.
Cygwin and mingw32 are now supported when configuring with
--disable-alloc and --disable-location (only debug output).
Threading had not been tested on cygwin, and doesn't work
on mingw32 (use --disable-threading).
Bug fixes:
On fedora core 2 it has happened that unnamed 'shared
libraries' are being mapped and listed in the dl_loaded
list. This caused libcwd to crash with the error:
FATAL : std::ifstream.open(""): ENOENT (No such file or directory)
A debug channel that was not included in the vector of
debug channels (as is used for ForAllDebugChannels),
like RCFILE, caused an ASCII 0 to be printed as part of its
string when later another channel with a larger name was
created.
'type_info_of' could not be used safely from constructors
of global objects.
Configuration with --disable-alloc caused problems when
using libcwd in a library.
libcwd-0.99.37
Added support for g++ 3.4.1.
The format of how a location_ct is written to an ostream
can now be controlled with libcwd::location_format().
It takes the same bit masks as the alloc filter, though
restricted to the flags 'show_objectfile', 'show_function'
and 'show_path'. Instead of printing "<unknown function>"
libcwd will now print the objectfile and the mangled
function name of that location.
The location at which memory is allocated is now also
printed at the moment the memory is allocated and not only
when it is being deleted. It is appended after the
return value of the allocation function in square brackets.
For example:
MALLOC : malloc(52) = 0x8076528 [ld-linux.so.2:_dl_map_object_deps]
list_allocations_on now returns the number of printed
allocations (unfiltered and not invisible). If that number
is different from the real number of allocation, it will
append a line like this one:
MALLOC : Number of visible memory blocks: 5\.
Note that 'visible' there means that it was printed, not
that they are not invisible (it is possible to have
not-invisible memory blocks not being printed when they are
being filtered by the ooam_filter_ct object that was passed).
Added was a function ooam_filter_ct::hide_functions_matching
that allows to hide allocations from the Overview Of Allocated
Memory that were allocated from a certain function (and a
certain shared library, if needed).
A new flag alloc_filter_ct::show_function was added, causing
list_allocations_on to print the mangled function name from
which an allocation was done, even when the sourcefile and
line number is known.
Two new functions have been added to namespace libcwd:
set_invisible_on() and set_invisible_off(). These should
be called in pairs, just like turning off and on the
debug channels. Any memory that is allocated while
invisibility is turned on will be invisible (hidden
from the allocated memory overview and any leak detection
you might have) automatically. Note that using this is
merely a special case of using a memory marker with
<code>invisible</code> set and using a filter that filters
everything; you might still want to use a marker and
use its filter for fine tuning, instead.
libcwd::ooam_filter_ct does not allocate normal memory anymore
(only `internal' memory) making it better suitable to use it
as a filter to show memory leaks at program termination.
Support for automake version 1.8 has been added.
API changes:
Two classes have been renamed:
ooam_filter_ct --> alloc_filter_ct
ooam_format_t --> alloc_format_ct
Where 'alloc' means 'memory allocation(s)'.
The reason for the change is that the filter is being used
in more and more places that are not directly related to the
Overview Of Allocated Memory (ooam).
location_ct::location_ct(void const*) has been made explicit.
libcwd-0.99.36
Libcwd is now compiled with -O2 by default.
Several files that shouldn't have been in the tar ball were
removed from the release.
The distclean target was fixed.
API changes:
The following methods have been removed from debug_ct:
void set_margin(std::string const& s);
void set_marker(std::string const& s);
std::string get_margin(void) const;
std::string get_marker(void) const;
Instead use debug_ct::margin() and debug_ct::marker()
and the methods of the class that is returned
(ie libcwd::debug_string_ct::assign).
See reference-manual/classlibcwd_1_1debug__ct.html
Bug fixes:
The example-project didn't compile because of the usage
of #ifdef instead of #if in debug.cc.
libcwd-0.99.35
Bug fixes:
It was not possible to make realloc()-ated memory invisible.
Changes:
Memory that was invisible and is then realloc()-ated will
now stay invisible. Memory that is allocated that is
invisible will have a "(invisible)" remark behind it.
For example:
MALLOC : realloc(0x84ad7f8, 64) = 0x849e5f8 (invisible)
API changes:
A new setup for libraries that use libcwd has been designed.
This new design allows third-party library headers to
include <libcwd/libraries_debug.h> (not <libcwd/debug.h>!)
The new design also requires library authors to define their
own ForAllDebugChannels and ForAllDebugObjects macro for use
in their headers files, if they need that. Before, this was
only needed for Dout, DoutFatal and Debug, but use of
ForAllDebug* was theoretically broken in library headers under
very specific circumstances [ involving two libraries that
both use libcwd and have a channel name collision which the
end-user resolves in favour of library1 while library2 uses
a ForAllDebug* macro in its headers and refers to the
colliding debug channel inside this ForAllDebug*; it then
would get the channel of the other library. ]
Moreover, as a result of this design, one should use
LIBCWD_DEBUGCHANNELS instead of DEBUGCHANNELS when using
this macro. You still *define* DEBUGCHANNELS, before including
<libcwd/debug.h>.
The means that the following changes need to be made.
End-application authors:
- Change all occurances of DEBUGCHANNELS, except the one where it
is defined (in your "debug.h"), into LIBCWD_DEBUGCHANNELS.
Library authors:
- Change all occurances of DEBUGCHANNELS in your source files
and local headers, except the one where it is defined (in your
local "debug.h"), into LIBCWD_DEBUGCHANNELS.
- Make sure you are not using DEBUGCHANNELS in your headers, if
you do - change it to the literal namespace (for example
'libwhatever::channels') of your library.
- Replace in your headers any occurance of 'ForAllDebug*(' with
'LibcwdForAllDebug*(libwhatever::channels, ', where 'ForAllDebug*'
is either ForAllDebugChannels or ForAllDebugObjects and
'libwhatever::channels' is the namespace in which your library
defines its 'dc' namespace with library specific debug channels,
or use your own macros for this (see url below).
- In your headers, replace
#ifndef LIBWHATEVER_DEBUG_H
#error "You need to include the appropriate debug.h in the \
source file, before including this header file."
#endif
with
#include <libwhatever/debug.h>
And read carefully the page on
reference-manual/group__chapter__custom__debug__h.html#libraries
for further instruction on how to set up respective debug header
files.
libcwd-0.99.34
Turning on of dc::malloc and dc::bfd in rcfile_ct::read is
delayed till all of the rcfile is processed. This prevents
printing of MALLOC and BFD messages in the case that those
channels are turned off at the start of processing the rcfile
even if they are temporarily turned on.
API changes:
Namespace libcw::debug has been replaced with namespace libcwd.
In most case you should be able to just replace all occurances
of 'libcw::debug' with libcwd without problems. If for some
reason this change has a too dramatic effect on your application
then you can also add this to your custom debug.h file:
namespace libcw { namespace debug = ::libcwd; }
directly after including libcwd/debug.h.
Bug fixes:
A Shared Object file with more than 256 .debug_abbrev entries
caused undefined behaviour. Thanks to Vladimir Prus for
reporting this problem.
The non-threaded library could core dump at exit due to a
global object destruction order fiasco. If libcw_do was
destructed before rcfile (or any other global object doing
memory allocations from its destructor) and dc::malloc is
still turned on.
libcwd-0.99.33
New function debug_watch(ptr). You can call this from within
gdb and it will cause a breakpoint when the memory pointer
ptr that is passed to it is being freed.
Added support for pkg-config(1).
See http://www.freedesktop.org/software/pkgconfig
This means you can use `pkg-config --cflags` and
`pkg-config --libs` in your configure script in order
to get the flags that libcwd needs.
The allocator implementation has been adjusted in order
to work again with the latest __pool_alloc of g++ 3.5 cvs.
Bug fixes:
The tar ball distribution was missing include/pch-source.h,
making it fail to compile with g++ 3.4 or higher.
Compilation failed when configured with --enable-maintainer-mode
because example-project/debug.h.maintainer is not distributed.
A workaround for this has been added.
libcwd-0.99.32
Support for a runtime configuration file (.libcwdrc) has been
added. This file can be used to set the debug channels.
A new function `attach_gdb()' was added. When called, it
opens a terminal window with a gdb session allowing one to
debug the application from that point onwards.
Documentation for both functions above has been added to the
reference manual.
The code was adjusted to support the latest CVS version of
the gcc-3_4-branch (20040220).
Code has been added to correct wrong debug info as outputted
by the commonly used GNU assembler version 2.3.90 as result
of a frequently occuring bug. Before this correction is was
possible that libcwd was unable to determine the line number
information of about 1% of the functions.
The library now prints "Loading debug symbols from..."
(if the environment variable LIBCWD_PRINT_LOADING is set)
and "Loading debug info from..." seperately.
A function was added that is intended to be called from gdb like:
(gdb) call debug_alloc(0x84002f2)
It prints information about the pointer passed to it. This
function can ONLY be called from within gdb, to assist in
debugging memory allocation related problems.
More bugs in the demangler have been fixed - however, if you
write code that actually needs the cases that have been fixed
then you should go and see a doctor.
Work In Progress:
The following is partically finished but not yet usable.
It won't be in the way of normal usage though.
- functions / stack stuff
- New test environment (cutee)
API changes:
The debug channel constructor was changed from
channel_ct::channel_ct(char const* label) to
channel_ct::channel_ct(char const* label, bool add_to_channel_list = true).
When add_to_channel_list is false, the channel will not be added
to the list of channels as accessible with ForAllDebugChannels().
Bug fixes:
It happened that the location of an allocation done before
libcwd is initialized would never get resolved, resulting
in weird output like:
MALLOC : malloc(352) = 0x805a4c8
MALLOC : free(0x805a4c8) <pre libcwd initialization> <unknown type>; (sz = 352)
Where the allocation of that specific instance clearly isn't
"pre libcwd initialization". The reason for this is that
locations are cached: the delayed lookup was never performed.
When libcwd could not determine the start of shared library
it would core dump with the message COREDUMP: bfd.cc:513:
void libcw::debug::cwbfd::bfile_ct::initialize(const char*, void*):
Assertion `!__libcwd_tsd.internal' failed.
This was because 'internal' was still set, while since 0.99.29
allocations inside Dout are treated as normal (non-internal).
Several potential deadlocks have been fixed (potential means
that I ran into a rare circumstance in which two locks were
called in the reverse order than is usual - it is a thousand times
less likely however that that happens at the same time another
thread is locking them too, in the right order, causing the
actual dead lock). All of these potential deadlocks were related
to initialization (and only would happen immedeately after
starting the application) and ranged from 'probably nobody ran
into this yet' to 'only when there really exist an infinite
number of parallel universes there is a slight chance that
this might actually happen - not in THIS universe however.'
libcwd-0.99.31
Support for the Native POSIX Threads Library (NPTL)
was added. 0.99.30 did work with glibc-2.3.2 but
only with LD_ASSUME_KERNEL set to "2.2.5" (no NPTL).
The development kernel 2.5 and the kernel that is
distributed with RedHat 9 do support NPTL and therefore
need this version.
API changes:
The method debug_ct::keep_tsd was removed.
This function is no longer needed. See README.threads
for a description of how Thread Specific Data of
terminating threads now is handled.
Bug fixes:
debug_tsd_st::finish accessed a bit in a memory block
that was just freed. As a result the 'flush_cf'
control flag could be propagated wrongly from an
'interupted' debug output to the output that it
interupted.
TLS symbols in a TLS enabled library (i.e. glibc-2.3.2
of RedHat 9) did confuse libcwd and could lead to a
wrong function name being resolved for a given address.
libcwd-0.99.30
Libcwd now works with glibc-2.3.2 (RedHat 9).
Bug fixes:
Several minor thread related bug fixes.
Threaded applications could errornously filter away
allocation in an allocated memory overview because
allocation made after between two calls to
list_allocations_on using the same filter would
be filtered on an uninitialized boolean.
libcwd-0.99.29
Allocations inside Dout() et al are not 'internal' anymore.
Although it makes no sense to explicitly allocate memory in
debug code, there were problems with implicitly allocated
memory as part of libstdc++ (like a locale object and a
scratch buffer for writing numbers), these allocation should
be non-internal - and when occuring from within a Dout did
sometimes lead to a COREDUMP, complaining about freeing
'internal' memory.
Support for 2.95.x and 2.96 (RedHat 7) has been dropped.
Minimum compiler requirement is now 3.0, 3.2.x is recommended.
This was necessary because these older versions don't
fully support string buffers with allocator support, they
are not standard compliant.
Libcwd now compiles and works with the (current) CVS branches
of g++ 3.3 and 3.4.
API changes:
The directory include/libcw was renamed to include/libcwd.
The headerfile sysd.h was renamed to sys.h.
The headerfile debug_config.h was renamed to config.h.
This means that you will have to update your debug.h and
sys.h files for the applications that use libcwd:
#include <libcw/sysd.h> --> #include <libcwd/sys.h>
#include <libcw/debug.h> --> #include <libcwd/debug.h>
And, in case you use these:
#include <libcw/cwprint.h> --> #include <libcwd/cwprint.h>
#include <libcw/buf2str.h> --> #include <libcwd/buf2str.h>
#include <libcw/char2str.h> --> #include <libcwd/char2str.h>
Bug fixes:
It could happen, while writing debug output, that you'd see
something like:
COREDUMP: internal free: You are 'free()'-ing a pointer with alloc
checking OFF ('internal' allocation) (0x807e570) that was allocated with
'malloc()'. Use 'free' instead.
Aborted (core dumped)
While in fact you didn't free anything at all (the free is
done internally by libstdc++ and out of your control).
This should be fixed now.
When one thread is listing memory allocations and another
thread is closing a shared library, it could happen that
a type_info reference in the listing did not exist anymore
by the time it was listed, resulting in a crash.
This was fixed with a mutex that excludes calls to dlclose
and listing memory allocation for all threads. Note that
this can still happen when a shared library is closed that
leaked memory.
Two threads reaching the same AllocTag at the same time,
and for the first time that it is reached (very unlikely
thus) caused a race condition on the static description
pointer. A critical area for the (one time) initialization
of the description has been added.
libcwd-0.99.28
Bug fixes:
Configuration with --disable-alloc was still broken on SunOS.
The mangling was changed in g++ version 3.1 (rendering C++ libraries
compiled with previous versions binary incompatible). The demangler
of libcwd was updated to reflect this change. As a result, libcwd
will not always correctly demangle applications that were compiled
with g++ versions 3.0.x anymore.
Under certain circumstances, the decoding of the line numbers
of DWARF2 .debug_line section failed. In particular, the
last source line of functions was failing often. Most notably
that was confusing when the last line of an inlined function
needed to be located. The lookup now has been extensively tested
(to correctly lookup every possible location in a -O2 compiled
libstdc++-5.0.2).
Only half of the new/delete signatures in <new> were supported.
As a result, applications that used new(std::nothrow_t) would
abort with the error: "COREDUMP: You are `delete'-ing a block that
was allocated with `malloc()'! Use `free()' instead."
In particular gtkmm-2.0 and higher is using such a call.
(Bug reported by Marek Materzok).
The following signatures have been added to libcwd now:
void* operator new(std::size_t, std::nothrow_t const&) throw();
void* operator new[](std::size_t, std::nothrow_t const&) throw();
void operator delete(void*, std::nothrow_t const&) throw();
void operator delete[](void*, std::nothrow_t const&) throw();
There is a bug in the g++ compiler that is not likely to be
fixed very soon; see http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=38
Therefore, a workaround for this bug was added in order to
make cwprint_using work when the print method is a method of
the base class. The latter now takes two template parameters:
template<T, T_OR_BASE_OF_T>
cwprint_using_tct<T_OR_BASE_OF_T>
cwprint_using(T const&, void (T_OR_BASE_OF_T::*)(std::ostream&) const);
dlopen() failed when a relative path was given. It now
also works when the filename is somewhere in LD_LIBRARY_PATH,
or /etc/ld.so.cache, etc., but only when glibc is used (more
precisely, libcwd assumes that the handle that is returned by
dlopen() is actually a link_map pointer).
If an object file has both stabs and DWARF2 debugging information
then the stabs information was ignored. This turns out not to be
correct because it is possible that there is line number information
in the .stabs section that is not in the .debug_line section when
the latter is part of the usual crt*.o object files of g++-2.95.x
in the case that this compiler was compiled with -gdwarf-2 or with
gcc-3.x. Libcwd now reads and combines the debugging info from
both kinds.
libcwd-0.99.27
Bug fixes:
Libcwd would core dump when reading the DWARF debug info from
a library whose last compilation unit did not contain a
.debug_line section.
Configuration with --disable-alloc was broken.
The demangler for the new ABI didn't demangle global
constructors/destructors keyed to functions (mangled names
starting with _GLOBAL__[ID]_, a GNU extension).
libcwd-0.99.26
Changes:
It is now possible to hide allocations from the Overview Of
Allocated Memory whose allocation location could not be determined.
Those allocations would always show up, using the function name
of the function where the allocation was done.
[ ooam_filter_ct::hide_unknown_locations(bool) ].
Support for glibc-2.2.5 has been added. This means that the
testsuite should not report errors anymore and that _dl_loaded
is detected and used again (as member of _rtdl_global).
Bug fixes:
Several README files that should have been part of the distribution
were not! Added: README.CVS (explains how to download libcwd
from cvs), README.solaris (explains that threading doesn't work
on solaris), README.threads (general information on how to debug
threaded applications).
The demangler was decoding 's' into "internal_string" instead of
"std::string". A left-over from an old find & replace.
There was still a problem with third party C++ libraries whose
first allocation - as part of the initialization of that library -
is from std::allocator. The initialization of libcwd now also
uses a private memory pool for 'userspace' allocations.
libcwd-0.99.25
Changes:
channel_ct::get_label() was returning a character array of size
max_label_len_c, right padded with spaces and not zero terminated.
Now it returns a zero terminated character array. The length
of the string is equal to the length of longest label (so dlopen-
ing a library with a longer debug channel will actually increase
the size of all other labels).
Bug fixes:
The previous version erroneously did not compile with -O.
When using g++ version 2.95.x or 2.96 then multi-threaded
applications could core dump because demangle_symbol and
demangle_type were not thread safe.
list_allocations_on only worked for libcw_do, not for a
custom debug object.
Memory leaks that were introduced in 0.99.20 have been fixed
for AllocTag (leaked 20 bytes, now does not allocate anything
at all to begin with) and list_allocations_on (the copy of the
memory allocation administration was never freed, ugh).
location_ct was leaking memory (the filename was never deleted).
When using a third party library (like libMagick++), it is
possible that the first allocation - as part of the initialization
of that library - is from std::allocator. The vector that is
being using to store all debug objects was erroneously using
std::allocator as well, causing a dead lock during the initialization
of libcwd for threaded applications in such a case.
libcwd-0.99.24
Bug fixes:
https://sourceforge.net/tracker/?func=detail&atid=449767&aid=573370&group_id=47536
has been fixed. When gcc is configured with --enable-sjlj-exceptions
then every call to C++ functions is accompanied by a call to
_Unwind_SjLj_Register that calls __pthread_setspecific that
calls calloc. We can't have that for two reasons: Firstly,
it causes easily an infinite recursion when a C++ function is
called from calloc (which is what we obviously do) and
secondly, when libcwd is doing internal allocations it also
calls (C++) functions which then would cause the allocations
done by __pthread_setspecific to be 'internal' and that causes
problems as well. The solution was to compile libcwd with
-fno-exceptions. Of course you can still use exceptions in
the applications that link with libcwd.
The configure options --disable-alloc and --disable-location
now work again.
When allocating 0xffffffff bytes, libcwd would - instead
of reporting an Out Of Memory - allocate 11 bytes and CORE when
you tried to free that memory again. The reason is that it
adds 12 to the size for the magic numbers. Now it will detect
large sizes and generate an Out Of Memory.
A possible core dump with a backtrace like:
#0 0x403cb4f1 in strlen () at strlen:-1
#1 0x400abbe9 in operator<< (os=@0x85a3748, data=0xbf7ff9dc "\002\001") at include/cwd_debug.h:55
#2 0x4008295f in libcw::debug::dm_alloc_base_ct::print_description(libcw::debug::ooam_filter_ct const&,
libcw::debug::_private_::TSD_st&) const (this=0x85a3748, filter=@0xbf7ff9dc,
__libcwd_tsd=@0x807ccc8) at debugmalloc.cc:1250
where 'a_type' (see debugmalloc.cc in frame #2) is NULL was fixed.
This could occur in multi-threaded applications when one thread
is using list_allocations_on() while another thread is demangling
a C++ type with demangle_type() or demangle_symbol().
Continued debug output now also works with multi-threading,
printing <unfinished> and <continued> as expected when a
different thread is writing output in the meantime.
The use of nonewline_cf in combination with other threads
will result in "<no newline>\n" being appended to unfinised
output, for example:
Thread1 NOTICE abcd<no newline>
Thread2 NOTICE interrupt
efgh
Note that in this case the prefix is not repeated. The use
of nonewline_cf in a multi-threaded application is therefore
dissuaded; use continued_cf instead to get for example:
Thread1 NOTICE abcd <unfinished>
Thread2 NOTICE interrupt
Thread1 NOTICE <continued> efgh
libcwd-0.99.23
The "Overview Of Allocated Memory" filter (ooam_filter_ct)
has been extended with the ability to discriminate on the
source filename of the allocation location
[ ooam_filter_ct::hide_sourcefiles_matching(std::vector<std::string> const&); ].
It is now also possible to only show allocations for which
explicitly an allocation annotation (AllocTag et al) has
been used [ ooam_filter_ct::hide_untagged_allocations(bool) ].
An allocation marker (marker_ct) now accepts a filter (ooam_filter_ct)
as second argument which is subsequently used to move 'hidden' allocations
outside of the marker before testing for leaks. Possible leaks are
then listed using the show_* flags of the filter.
Bug fixes:
dlopen() can now be called multiple times for the same module;
the related symbol table will not be deleted until dlclose()
has been called as often as dlopen() was called.
An allocation done in an object file that was opened with dlopen()
would cause a core dump in list_allocations_on when using a filter
with show_objectfile when in the meantime dlclose() was called
for that object file.
The first part of the full path of a source file location was
missing when using gcc 3.x.
libcwd-0.99.22
Bug fixes:
Using error_cf while interrupting continued_cf debug
output could cause errno to be set to EINTR before
printing the error message, in threaded applications.
DoutFatal in thread applications could cause a deadlock
because cancelling the main thread and then calling
exit() causes the main thread to call waitpid()
for the thread manager (which is already dead at that