http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2162
------- Comment #8 from jyoung@xxxxxxx 2008-01-06 06:32 GMT -------
Hello Jeff,
There was a second bug, in uat_unesc(). See Bug 2169.
If I hadn't been so aggressive in my "<snip>s" of the valgrind reports I posted
it would have been obvious (to someone used to looking at valgrind reports)
that the buffer in question presented to ep_strndup() was dynamically
allocated.
So for the record, here's the complete set of valgrind messages for one example
of this bug:
== 13499== Invalid read of size 1
== 13499== at 0x445D672: ep_strndup (emem.c:515)
== 13499== by 0x4B6262D: snmp_users_priv_proto_set_cb
(packet-snmp-template.c:1888)
== 13499== by 0x44A357F: uat_load_lex (uat_load.l:177)
== 13499== by 0x44A4A36: uat_load (uat_load.l:269)
== 13499== by 0x4497613: uat_load_all (uat.c:315)
== 13499== by 0x446AE57: init_prefs (prefs.c:1080)
== 13499== by 0x446B36F: read_prefs (prefs.c:1245)
== 13499== by 0x8087B69: main (main.c:2506)
== 13499== Address 0xb612c2b is 0 bytes after a block of size 3 alloc'd
== 13499== at 0x401CD49: calloc (vg_replace_malloc.c:397)
== 13499== by 0x61F24E2: g_malloc0 (in
/opt/gnome/lib/libglib-2.0.so.0.800.1)
== 13499== by 0x4497BE0: uat_unesc (uat.c:466)
== 13499== by 0x449802D: uat_undquote (uat.c:559)
== 13499== by 0x44A32D5: uat_load_lex (uat_load.l:145)
== 13499== by 0x44A4A36: uat_load (uat_load.l:269)
== 13499== by 0x4497613: uat_load_all (uat.c:315)
== 13499== by 0x446AE57: init_prefs (prefs.c:1080)
== 13499== by 0x446B36F: read_prefs (prefs.c:1245)
== 13499== by 0x8087B69: main (main.c:2506)
Of course the first line (Invalid read of size 1) indicates the attempt to read
the non-existant buf[3] that occured in ep_strndup().
But it was the line that has the text "Address 0xb612c2b is 0 bytes after a
block of size 3 alloc'd" that actually reported where in memory the buf[3]
location was. This same message indicated that this location is just beyond a
three byte dynamic allocation.
Valgrind then followed that particular message with essentially a back trace of
the call stack that had actually allocated the preceeding buffer!
Once I realized what this WHOLE set of valgrind messages was actually
indicating it was relatively easy to bring up gdb, add some breakpoints, step
into uat_unesc() and see another problem.
I know it will be worthwhile to put a Valgrind page up on the Development
section of wiki. I'll see what I can do.
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.