Comment # 3
on bug 12656
from Guy Harris
Or maybe valgrind is confused on OS X 10.11 and can't figure out what's leaked
and what isn't.
This:
==32103== 14,976 bytes in 117 blocks are possibly lost in loss record 2,859 of
2,869
==32103== at 0x100054D81: malloc (vg_replace_malloc.c:303)
==32103== by 0x10180CE72: _vasprintf (in /usr/lib/system/libsystem_c.dylib)
==32103== by 0x1001EFA59: g_vasprintf (in
/usr/local/lib/libglib-2.0.0.dylib)
==32103== by 0x1001CAC68: g_strdup_printf (in
/usr/local/lib/libglib-2.0.0.dylib)
==32103== by 0x10531DA28: proto_register_qsig (packet-qsig-template.c:622)
==32103== by 0x1054A5E1B: register_all_protocols (register.c:3446)
==32103== by 0x104882173: proto_init (proto.c:528)
==32103== by 0x104865B5E: epan_init (epan.c:127)
==32103== by 0x10000C0F3: main (tshark.c:800)
comes from a bunch of formatted OID strings being inserted into a hash table;
I'm not sure how
for (i=0; i<array_length(qsig_op_tab); i++) {
opcode = qsig_op_tab[i].opcode;
oid = g_strdup_printf("1.3.12.9.%d", opcode);
key = (gint *)g_malloc(sizeof(gint));
*key = opcode;
g_hash_table_insert(qsig_opcode2oid_hashtable, key, oid);
g_hash_table_insert(qsig_oid2op_hashtable, g_strdup(oid),
(gpointer)&qsig_op_tab[i]);
}
is going to leak memory - g_hash_table_insert() just sticks the pointers into
hash table entries, so, unless valgrind can't dig through a GHashTable....
You are receiving this mail because:
- You are watching all bug changes.