I'm running 0.10.3 on FreeBSD 4.9 and can see the following problem:
When tethereal is invoked in ring buffer capture mode the program will
abort via an assertion at line 1942 of wiretap/libpcap.c in
libpcap_dump(). See below for some relevent gdb output.
All sorts of different filesize and duration paremeters will reproduce the
problem; for example:
tethereal -w c.dat -a filesize:5000 -b 128:900 -s 1500 -i fxp1
I haven't tried 0.10.4 yet, but the diffs for tethereal and the wiretap
package don't suggest many changes from what I am running.
Any ideas?
-Chris
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[ ethereal 0.10.3 sources ]
Core was generated by `tethereal'.
Program terminated with signal 6, Abort trap.
.
.
.
(gdb) bt
#0 0x28bf3fc0 in kill () from /usr/lib/libc.so.4
#1 0x28c35882 in abort () from /usr/lib/libc.so.4
#2 0x28b523be in g_logv () from /usr/local/lib/libglib12.so.3
#3 0x28b52475 in g_log () from /usr/local/lib/libglib12.so.3
#4 0x2809073c in libpcap_dump (wdh=0x8152b00, phdr=0xbfbef07c,
pseudo_header=0xbfbeefec, pd=0x8194012 "", err=0xbfbeef54)
at libpcap.c:1942
#5 0x2808b3e7 in wtap_dump (wdh=0x8152b00, phdr=0xbfbef07c,
pseudo_header=0xbfbeefec, pd=0x8194012 "", err=0xbfbeef54)
at file_access.c:674
#6 0x8059abe in wtap_dispatch_cb_write (user=0xbfbeefe0 "",
phdr=0xbfbef07c, offset=0, pseudo_header=0xbfbeefec, buf=0x8194012 "")
at tethereal.c:2471
#7 0x8059469 in capture_pcap_cb (user=0x8065760 "\001", phdr=0x8194000,
pd=0x8194012 "") at tethereal.c:2111
#8 0x28b8bc92 in pcap_read_bpf (p=0x811aa00, cnt=1, callback=0x80593f4
<capture_pcap_cb>, user=0x8065760 "\001")
at ./pcap-bpf.c:276
#9 0x28b8846c in pcap_dispatch (p=0x811aa00, cnt=1, callback=0x80593f4
<capture_pcap_cb>, user=0x8065760 "\001") at ./pcap.c:73
#10 0x8058ff2 in capture (out_file_type=2) at tethereal.c:1942
#11 0x805898f in main (argc=15, argv=0xbfbff970) at tethereal.c:1594
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
It looks as though the (struct wdh *) which wtap_dump() passes to
libpcap_dump() points to a structure with a corrupted wdh->file_type
value. I'm guessing we would want to see WTAP_FILE_PCAP (2) in the
file_type field since we're saving in pcap format. What we have instead:
(gdb) up
#5 0x2808b3e7 in wtap_dump (wdh=0x8152b00, phdr=0xbfbef07c,
pseudo_header=0xbfbeefec, pd=0x8194012 "", err=0xbfbeef54)
at file_access.c:674
674 return (wdh->subtype_write)(wdh, phdr, pseudo_header, pd,
err);
(gdb) print wdh
$1 = (wtap_dumper *) 0x8152b00
(gdb) print *wdh
$2 = {fh = 0x0, file_type = 136069120, snaplen = 393280, encap = 4194367,
bytes_dumped = -2, dump = {opaque = 0xffffffff,
ngsniffer = 0xffffffff, netmon = 0xffffffff, netxray = 0xffffffff,
_5views = 0xffffffff, niobserver = 0xffffffff},
subtype_write = 0x280905f4 <libpcap_dump>, subtype_close = 0}
When libpcap_dump() looks at wdh->file_type and doesn't find any known
values, it triggers the assert at line #1942.
I'm wondering if there is some sort of race condition occuring between the
file saving operation being attempted in wtap_dump() and the ongoing
packet capturing being done with the pcap library itself?
