Hello list,
I'm using the newly-released XML output mode (-T pdml) of tethereal. Thanks
very much for adding it -- it's exactly what I need!
Unfortunately, on some packets, tethereal -T pdml falls over with:
Unhandled exception ("XCEPT_GROUP_ETHEREAL", group=1, code=2)
Aborted
I've included a two-packet trace, a request and reply, that causes this
behavior on the reply packet. In my 154-packet trace, about 15 packets cause
tethereal to die this way. (I can supply more of the trace if someone is
interested in digging into it further.)
Thanks!
--Jon
Lots of tedious debugging info follows; it may or may not be useful since I
don't know my way around the ethereal source code.
Version: ethereal-0.10.0a
Uname -a: Linux eustace 2.4.21 #1 Tue Sep 16 19:25:45 PDT 2003 i686 Pentium
III (Coppermine) GenuineIntel GNU/Linux
Stack trace from gdb:
(gdb) where
#0 0x4019ef81 in kill () from /lib/libc.so.6
#1 0x4019ed15 in raise () from /lib/libc.so.6
#2 0x401a026b in abort () from /lib/libc.so.6
#3 0x0841d918 in unhandled_catcher (except=0xbffff030) at except.c:213
#4 0x0841d8d6 in do_throw (except=0xbffff030) at except.c:205
#5 0x0841da9d in except_throw (except_group=1, except_code=2,
msg=0x86f06c4 "XCEPT_GROUP_ETHEREAL") at except.c:269
#6 0x0842d01d in ensure_contiguous (tvb=0x890c9d0, offset=90, length=4324)
at tvbuff.c:835
#7 0x0842d57e in tvb_get_ptr (tvb=0x890c9d0, offset=90, length=4324)
at tvbuff.c:994
#8 0x083e9022 in get_field_data (src_list=0x88c97e8, fi=0x890d948)
at print.c:142
#9 0x083e92eb in print_field_hex_value (pdata=0xbffff3a0, fi=0x890d948)
at print.c:239
#10 0x083e9441 in proto_tree_print_node_pdml (node=0x890c5c0, data=0xbffff3a0)
at print.c:281
#11 0x084216ab in proto_tree_children_foreach (tree=0x890c2a8,
func=0x83e932e <proto_tree_print_node_pdml>, data=0xbffff3a0)
at proto.c:387
#12 0x083e975b in proto_tree_print_node_pdml (node=0x890c2a8, data=0xbffff3a0)
at print.c:369
#13 0x084216ab in proto_tree_children_foreach (tree=0x891db58,
func=0x83e932e <proto_tree_print_node_pdml>, data=0xbffff3a0)
at proto.c:387
#14 0x083e8fa0 in proto_tree_print (print_args=0xbffff410, edt=0x890bf20,
fh=0x4029dd80) at print.c:115
#15 0x083fe4ca in wtap_dispatch_cb_print (user=0xbffff508 "K\200\b",
phdr=0x88e7208, offset=208, pseudo_header=0x88e721c, buf=0x8954030 "")
at tethereal.c:2548
#16 0x08411bd8 in wtap_loop (wth=0x88e71f0, count=0,
callback=0x83fe304 <wtap_dispatch_cb_print>, user=0xbffff508
"K\200\b",
err=0xbffff518) at wtap.c:357
#17 0x083fdccf in load_cap_file (cf=0x8804ba0, out_file_type=2)
at tethereal.c:2228
#18 0x083fc9d7 in main (argc=5, argv=0xbffff754) at tethereal.c:1463
#19 0x4018b7a6 in __libc_start_main () from /lib/libc.so.6
At frame #6, in tvbuff.c, the exception comes from p==NULL; the offending
assignment at line 832:
832 p = ensure_contiguous_no_exception(tvb, offset, length,
&exception);
Here are the values of those parameters:
(gdb) print *tvb
$3 = {type = TVBUFF_REAL_DATA, initialized = 1, usage_count = 2,
ds_tvb = 0x890c9d0, used_in = 0x88c97f0, tvbuffs = {subset = {tvb = 0x0,
offset = 0, length = 0}, composite = {tvbs = 0x0, start_offsets = 0x0,
end_offsets = 0x0}}, real_data = 0x8954030 "", length = 1514,
reported_length = 1514, raw_offset = 0, free_cb = 0}
(gdb) print offset
$4 = 90
(gdb) print length
$5 = 4324
Hmm. Notably, length is longer than the packet. Hmm.
(gdb) print *(fi->rep)
$14 = {representation = "Trans2 Response (0x32)", '\0' <repeats 217 times>}
I'm pretty much completely ignorant of ethereal's architecture, so at this
point, I'm kinda lost. grep "Trans2 Response" * doesn't show me where this
data structure might have come from, so I'll have to go on looking. But I'm
sending this note now in case someone who is familiar with ethereal can find
the bug in no time by running it on my packet trace.Attachment:
trace.broken2
Description: Binary data
