Comment # 3
on bug 9247
from Jakub Zawadzki
(In reply to comment #2)
> Can you at least post output of gdb bt full (best tshark compiled with -O0).
>
> Does tshark crash when you run:
>
> /tmp/wsroot/bin/tshark -r base.pcap
> or
> /tmp/wsroot/bin/tshark -r base.pcap -2
> or
> /tmp/wsroot/bin/tshark -r base.pcap -Y smtp
> or
> /tmp/wsroot/bin/tshark -r base.pcap -2 -Y smtp
> ?
>
>
> and are you sure about bisection?
>
> i.e. is b68e6dcc429d9dc8e0996c98c1e7ab3e38d75144 (r50590) last working commit
> and d296ebc5254f78f5c18cd066fc886002b900a0a8 (r50591) first not working one?
Ok it actually makes sense if we have exception throwed during
tvb_clone_offset_len()
old reassembly code was doing:
fd->data = "" char *)g_malloc(fd->len);
tvb_memcpy(tvb, fd->data, offset, fd->len);
so even if tvb_memcpy() throwed exception fd->data was not NULL (fd->data had
crap inside, but it didn't crash).
Now if tvb_memcpy() throws exception it can be NULL.
Could you add to reassemble.c:
fd->tvb_data = (void *) 0xdeadbeaf;
before:
1021 fd->tvb_data = tvb_clone_offset_len(tvb, offset, fd->len);
run tshark again and check if it crashes with tvb address 0xdeadbeaf ?
You are receiving this mail because:
- You are watching all bug changes.