Re: [python] leaks from pretty printers

[Tom Tromey <tromey at redhat dot com>]

Some notes on a few of the remaining valgrind errors...

Paul> ==19223==    at 0x4C1FDF1: realloc /home/kcc/depot2-kcc-ts_valgrind-client/google_vendor_src_branch/valgrind/trunk/coregrind/m_replacemalloc/vg_replace_malloc.c:456
Paul> ==19223==    by 0x5D85685: vasprintf /usr/grte/v1/debug-src/src/glibc-2.3.6/libio/vasprintf.c:83
Paul> ==19223==    by 0x40B7A6: xstrvprintf /home/ppluzhnikov/Archive/archer/obj.64/gdb/../../gdb/utils.c:1194
Paul> ==19223==    by 0x40B655: xstrprintf /home/ppluzhnikov/Archive/archer/obj.64/gdb/../../gdb/utils.c:1170
Paul> ==19223==    by 0x430771: add_packet_config_cmd /home/ppluzhnikov/Archive/archer/obj.64/gdb/../../gdb/remote.c:867

This one is ignorable.  We should probably just have a valgrind
suppression for it.

Paul> ==19223==    at 0x4C1F9DC: malloc /home/kcc/depot2-kcc-ts_valgrind-client/google_vendor_src_branch/valgrind/trunk/coregrind/m_replacemalloc/vg_replace_malloc.c:207
Paul> ==19223==    by 0x40B46C: xmalloc /home/ppluzhnikov/Archive/archer/obj.64/gdb/../../gdb/utils.c:1100
Paul> ==19223==    by 0x40A32D: make_my_cleanup2 /home/ppluzhnikov/Archive/archer/obj.64/gdb/../../gdb/utils.c:330
Paul> ==19223==    by 0x40A3A9: make_my_cleanup /home/ppluzhnikov/Archive/archer/obj.64/gdb/../../gdb/utils.c:346
Paul> ==19223==    by 0x40A0DD: make_cleanup /home/ppluzhnikov/Archive/archer/obj.64/gdb/../../gdb/utils.c:201
Paul> ==19223==    by 0x4ABC51: read_string /home/ppluzhnikov/Archive/archer/obj.64/gdb/../../gdb/valprint.c:1261

Oops, the cleanup code in read_string is not correct.
Phil, the fix for this one must also go upstream.

Paul> ==19223==    at 0x4C1C334: calloc /home/kcc/depot2-kcc-ts_valgrind-client/google_vendor_src_branch/valgrind/trunk/coregrind/m_replacemalloc/vg_replace_malloc.c:422
Paul> ==19223==    by 0x40B539: xcalloc /home/ppluzhnikov/Archive/archer/obj.64/gdb/../../gdb/utils.c:1146
Paul> ==19223==    by 0x40B4A0: xzalloc /home/ppluzhnikov/Archive/archer/obj.64/gdb/../../gdb/utils.c:1110
Paul> ==19223==    by 0x49699C: allocate_value_contents /home/ppluzhnikov/Archive/archer/obj.64/gdb/../../gdb/value.c:270
Paul> ==19223==    by 0x4969CB: allocate_value /home/ppluzhnikov/Archive/archer/obj.64/gdb/../../gdb/value.c:279
Paul> ==19223==    by 0x49711A: value_copy /home/ppluzhnikov/Archive/archer/obj.64/gdb/../../gdb/value.c:658
Paul> ==19223==    by 0x497984: set_internalvar /home/ppluzhnikov/Archive/archer/obj.64/gdb/../../gdb/value.c:972

This one is already fixed upstream.
A merge from master will fix it; I've been meaning to do one but Jan's
notes on this topic have given me some pause.  I wonder what the best
approach is to repair the damage.

Paul> ==19223==    at 0x4C1F9DC: malloc /home/kcc/depot2-kcc-ts_valgrind-client/google_vendor_src_branch/valgrind/trunk/coregrind/m_replacemalloc/vg_replace_malloc.c:207
Paul> ==19223==    by 0x40B4E4: xrealloc /home/ppluzhnikov/Archive/archer/obj.64/gdb/../../gdb/utils.c:1126
Paul> ==19223==    by 0x561850: vec_o_reserve /home/ppluzhnikov/Archive/archer/obj.64/gdb/../../gdb/vec.c:100
Paul> ==19223==    by 0x5617F8: vec_p_reserve /home/ppluzhnikov/Archive/archer/obj.64/gdb/../../gdb/vec.c:83
Paul> ==19223==    by 0x48A098: VEC_bp_location_p_reserve /home/ppluzhnikov/Archive/archer/obj.64/gdb/../../gdb/breakpoint.h:341
Paul> ==19223==    by 0x48A029: VEC_bp_location_p_safe_push /home/ppluzhnikov/Archive/archer/obj.64/gdb/../../gdb/breakpoint.h:341
Paul> ==19223==    by 0x489D2F: update_global_location_list /home/ppluzhnikov/Archive/archer/obj.64/gdb/../../gdb/breakpoint.c:6899

Ditto.

Tom