Ethereal-dev: Re: [Ethereal-dev] valgrind results

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Dr. Uwe Girlich" <Uwe.Girlich@xxxxxxxxxxx>
Date: Tue, 19 Nov 2002 15:46:29 +0100
Hello!

> > One of the summary line at the end reads:
> > ==23444== malloc/free: in use at exit: 1429768 bytes in 7116 blocks.
> > Should we try to reduce this number or is it not so important?
> Can you get a list of where in the code these blocks were allocated?
Some interesting points were:
==28206== 16 bytes in 1 blocks are definitely lost in loss record 1 of 7
==28206==    at 0x40043639: malloc (vg_clientfuncs.c:100)
==28206==    by 0x402F5A29: __strdup (in /lib/libc-2.1.3.so)
==28206==    by 0x439804DE: ???
==28206==    by 0x439808F7: ???
==28206==    by 0x4035B946: __gethostbyaddr_r (../nss/getXXbyYY_r.c:182)
==28206==    by 0x4035B732: gethostbyaddr (in /lib/libc-2.1.3.so)
==28206==    by 0x81D1BE1: host_name_lookup (resolv.c:314)
==28206==    by 0x81D2ED7: get_hostname (resolv.c:1377)
==28206==    by 0x81CBAA6: col_set_addr (column-utils.c:390)
==28206==    by 0x81CC197: fill_in_columns (column-utils.c:599)
==28206==    by 0x81CC4D7: epan_dissect_fill_in_columns (epan.c:135)
==28206==    by 0x81BC06A: wtap_dispatch_cb_print (tethereal.c:1786)
==28206==    by 0x81C6DAD: wtap_loop (wtap.c:315)
==28206==    by 0x81BBBC8: load_cap_file (tethereal.c:1486)
==28206==    by 0x81BB063: main (tethereal.c:868)

==28069== 780 bytes in 203 blocks are definitely lost in loss record 4 of 7
==28069==    at 0x40043639: malloc (vg_clientfuncs.c:100)
==28069==    by 0x40254236: g_malloc (in /usr/lib/libglib-1.2.so.0.0.6)
==28069==    by 0x81CDB17: dissector_add (packet.c:449)
==28069==    by 0x8071E6B: proto_reg_handoff_aodv (packet-aodv.c:402)
==28069==    by 0x81B9CC0: register_all_protocol_handoffs (register.c:328)
==28069==    by 0x81CE701: proto_init (proto.c:248)
==28069==    by 0x81CC3CB: epan_init (epan.c:53)
==28069==    by 0x81BA587: main (tethereal.c:379)

To reduce the number of "still reachable" blocks we need to implement a 2 stage
"done" function for every dissector, where it can first deregister its
dissector routine and in the second stage free its own ressources (which may
consist of now-empty dissector tables).

Bye, Uwe