Jeff Morriss
changed
bug 8653
Comment # 5
on bug 8653
from Jeff Morriss
(In reply to comment #4)
> (In reply to comment #3)
> > This capture runs clean for me (through tools/test-fuzzed-cap.sh and
> > tools/valgrind-wireshark.sh). Buildbot indicates it got a core dump.
> >
> > OK, Valgrind does have one warning here but I don't think this would have
> > caused a core dump:
> >
> > ==26458== Invalid read of size 1
> > ==26458== at 0x40DCA5: print_hex_data_buffer (print.c:1005)
> > ==26458== by 0x40F6B8: print_hex_data (print.c:922)
> > ==26458== by 0x417456: print_packet (tshark.c:3648)
> > ==26458== by 0x418C6F: process_packet (tshark.c:3253)
> > ==26458== by 0x40B141: main (tshark.c:3031)
> > ==26458== Address 0x1595d7e0 is 0 bytes inside a block of size 2 free'd
> > ==26458== at 0x4A077E6: free (vg_replace_malloc.c:446)
> > ==26458== by 0x354CA4D79E: g_free (in /usr/lib64/libglib-2.0.so.0.3400.2)
> > ==26458== by 0x61859AB: emem_free_all (emem.c:1180)
> > ==26458== by 0x61883D8: epan_dissect_run_with_taps (epan.c:221)
> > ==26458== by 0x418ABF: process_packet (tshark.c:3236)
> > ==26458== by 0x40B141: main (tshark.c:3031)
>
> No, this shouldn't cause a dump. It's a small but annoying place that's
> using ephemeral memory where it shouldn't but I've been unable to track down
> where it's coming from. Any ideas where hex data buffers might be allocated
> with ep_alloc?
The last time I saw that was in bug 8197; there I said:
~~~
The first ("invalid read of size 1") is because tvb_new_octet_aligned() is
returning an ep_alloc'd buffer which is then being added as a data source
(add_new_data_source()). I still need to go back and read about why ep_
allocations started disappearing after dissection is complete but before we're
done displaying what we've dissected. Anyway, this isn't causing the crash.
~~~
May not be exactly the same but it's probably add_new_data_source() which is
ep_alloc()'d.
You are receiving this mail because:
- You are watching all bug changes.