On 12/01/2012 10:54 PM, Evan Huus wrote:
On Sat 01 Dec 2012 10:47:47 PM EST, Jeff Morriss wrote:
On 12/01/2012 10:23 PM, Evan Huus wrote:
This sounds like something wmem could solve - if there is an
intermediate scope between ep and se in duration then it should be
possible to create another wmem scope for use here.
Yeah, I thought so too but I took the quick way out (to shut the
buildbot up).
Is the needed scope for these addresses well defined?
I'm not entirely sure, but it is (apparently) at least the old ep_
scope (in that the memory needs to be around at least until we *start*
dissecting the next packet). At least one of the dissectors I looked
at used (non-static!) local variables to hold their AT_STRINGZ. :-(
Ouch.
I'm not sure either, but I think the addresses might need to stick
around a little longer than that - maybe the length of the current
dissection (ie until the file is loaded or the filter has finished
running etc). That strikes me as a nice middle-ground between ep and se,
although it may be unnecessarily long for this particular case.
Where exactly were the addresses being used that was after the ep memory
was freed?
This is what Valgrind said which is what helped me find it:
==22974== Invalid read of size 1
==22974== at 0x4A09182: strlen (mc_replace_strmem.c:403)
==22974== by 0x60E5D02: emem_strdup (emem.c:971)
==22974== by 0x60DBFD8: se_get_addr_name (addr_resolv.c:996)
==22974== by 0x60E0D94: col_set_addr.isra.0 (column-utils.c:1429)
==22974== by 0x60E40D3: col_fill_in (column-utils.c:1731)
==22974== by 0x419549: print_packet (tshark.c:3508)
==22974== by 0x41AF16: process_packet (tshark.c:3177)
==22974== by 0x40DB52: main (tshark.c:2959)
==22974== Address 0xe6a53f0 is 0 bytes inside a block of size 13 free'd
==22974== at 0x4A07786: free (vg_replace_malloc.c:446)
==22974== by 0x35ACC4D50E: g_free (in /usr/lib64/libglib-2.0.so.0.3200.4)
==22974== by 0x60E652B: emem_free_all (emem.c:1239)
==22974== by 0x60E9048: epan_dissect_run_with_taps (epan.c:216)
==22974== by 0x41AC6E: process_packet (tshark.c:3160)
==22974== by 0x40DB52: main (tshark.c:2959)
