Jeff Morriss
changed
bug 8030
| What |
Removed |
Added |
| Status |
CONFIRMED
|
RESOLVED
|
| CC |
|
[email protected]
|
| Resolution |
---
|
FIXED
|
Comment # 7
on bug 8030
from Jeff Morriss
The Valgrind script (once modified to run tshark without "-Vx") gave warnings
of this sort:
~~~
==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)
~~~
The problem was that the dissector was storing its address (AT_STRINGZ) in ep_
allocated memory. It's not the only one doing this... :-(
Fixed (at least for one dissector) in r46320.
You are receiving this mail because:
- You are watching all bug changes.