Re: strange crash when a display filter is cleared on a reassembled packet

[mmann78 () netscape net]

Could the display filter crash be related to:

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5284  or
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6031 (duplicate of 5284, but the description is closer to yours)

or 
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6172

Mike




-----Original Message-----
From: Martin Kaiser <lists () kaiser cx>
To: wireshark-dev <wireshark-dev () wireshark org>
Sent: Thu, Sep 1, 2011 7:38 am
Subject: Re: [Wireshark-dev] strange crash when a display filter is cleared on a reassembled packet


Hmm, no response...
I wasn't expecting people to spend time on reproducing this but I was
oping that the backtrace would ring a bell for someone.
Yesterday, I played with DLNA traces and various wireshark versions
down to 1.4.8). There's also been regular crashes when I cleared
isplay filters :-(
So I'm tempted to say it's unrelated to my DVB-CI code but it's
omething particular for the FC15 box I'm running....
BTW another backtrace for the DVB-CI scenario described below is 
#0  0x41427f4a in IA__gtk_label_new (str=
   0x2e2e202e <Address 0x2e2e202e out of bounds>) at gtklabel.c:1398
1  0x0809e68e in add_byte_tab (byte_nb=0x8cc2048 [GtkNotebook], name=
   0x2e2e202e <Address 0x2e2e202e out of bounds>, tvb=0x2e2e3030, tree=
   0xb7af1000, tree_view=0x8cb8208 [GtkTreeView]) at
ain_proto_draw.c:708
2  0x080a04a1 in add_byte_views (edt=0x8d66548, tree_view=
   0x8cb8208 [GtkTreeView], byte_nb_ptr=0x8cc2048 [GtkNotebook])
   at main_proto_draw.c:801
3  0x080a04f1 in add_main_byte_views (edt=0x8d66548) at
ain_proto_draw.c:779
in add_byte_views():
(gdb) print edt->pi.data_src
7 = 0x8d3e720 = {0xb70f3000, 0xb70f301c, 0xb70f3038}
> that's the Frame, reassembled TPDU and reassembled SPDU data sources
(gdb) print *(data_source *)0xb70f3000
8 = {tvb = 0x8dcec90, name_initialized = 0, name = 0x14d40c7 "Frame"}
gdb) print *(data_source *)0xb70f301c
9 = {tvb = 0x2e2e3030, name_initialized = 774778400, name = 
   0x2e2e202e <Address 0x2e2e202e out of bounds>}
> this one's content is invalid and still passed on to other routines,
  leading to a crash
Any idea how to shed some light on this?
Best regards,
   Martin
Thus wrote Martin Kaiser (lists () kaiser cx):
> Dear all,
> I'm struggling with a strange crash, I'd really appreciate your help.
> It may be that my DVB-CI dissector, other parts of wireshark or my
 system configuration is at fault...
> current svn on a Fedora Core 15 linux
 TShark 1.7.0 (SVN Rev Unknown from unknown)
> Copyright 1998-2011 Gerald Combs <gerald () wireshark org> and
 contributors.  This is free software; see the source for copying
 conditions. There is NO warranty; not even for MERCHANTABILITY or
 FITNESS FOR A PARTICULAR PURPOSE.
 Compiled (32-bit) with GLib 2.28.8, with libpcap 1.1.1, with libz 1.2.5,
 with POSIX capabilities (Linux), with threads support, without libpcre,
 without SMI, without c-ares, without ADNS, without Lua, with Python
 2.7.1, with GnuTLS 2.10.5, with Gcrypt 1.4.6, with MIT Kerberos, without
 GeoIP.
 Running on Linux 2.6.40-4.fc15.i686.PAE, with locale en_US.UTF-8, with
 libpcap version 1.1.1, with libz 1.2.5.
 Built using gcc 4.6.0 20110603 (Red Hat 4.6.0-10).

 The problem can be reproduced by setting a display filter to
 dvb-ci.apdu_tag
 so that only APDUs are displayed
> Next, load http://www.kaiser.cx/misc/crash5.pcap, select packet 53
 (Profile Information) and click on Clear to clear the display filter
> This causes a segfault, backtrace is
> #0  ensure_contiguous_no_exception (tvb=0xcb5af808, offset=0, length=-1, 
     exception=0xbfffd4dc) at tvbuff.c:852
 #1  0x0072e2c3 in ensure_contiguous (tvb=<optimized out>, 
     offset=<optimized out>, length=-1) at tvbuff.c:887
 #2  0x080a01f9 in get_byte_view_data_and_length (byte_view=
     0x8cc62f8 [GtkTextView], data_len=0xbfffd53c) at

 Packet 53 is reassembled on both session and transport layer
 There are 3 data sources: Frame (13 Bytes), reassembled tpdu (35 bytes),
 reassembled spdu (128 bytes).
> Setting a breakpoint in ensure_contiguous_no_exception() before pressing
 the clear button shows the following

 -> the Frame (13 bytes)
 (gdb) print *tvb
 $12 = {type = TVBUFF_REAL_DATA, initialized = 1, usage_count = 2, ds_tvb = 
x8dd6cc8, used_in = 0x8dc5708 = {0x8dd6c20}, tvbuffs = {subset = {tvb = 0xffff, 
ffset = 1710618, length = 437918234}, composite = {tvbs = 0xffff = {<error 
eading variable>}, real_data = 0x822581c "", length = 13, reported_length = 13, 
aw_offset = 0, free_cb = 0}
 (gdb) cont 
 Continuing.
> -> Reassembled TPDU (35 Bytes)
 Breakpoint 2, ensure_contiguous_no_exception (tvb=0x8dd6c58, offset=0,
 length= -1, exception=0xbfffd4dc) at tvbuff.c:849 849     {
 (gdb) print *tvb
 $13 = {type = TVBUFF_REAL_DATA, initialized = 1, usage_count = 2, ds_tvb = 
x8dd6c58, used_in = 0x8dbc018 = {0x8ddde78}, tvbuffs = {subset = {tvb = 0xffff, 
ffset = 1710618, length = 437918234}, composite = {tvbs = 0xffff = {<error 
eading variable>}, real_data = 0x8cd0aa8 " !\001", 'ÿ' <repeats 32 times>, 
ength = 35, reported_length = 35, raw_offset = 0, free_cb = 0}
> -> next, ensure_contiguous_no_exception() is called with an illegal
 address as tvb *
> Breakpoint 2, ensure_contiguous_no_exception (tvb=0xb7e82720, offset=0,
 length= -1, exception=0xbfffd4dc) at tvbuff.c:849 849     {
 (gdb) print *tvb
 $14 = {type = 16927523, initialized = 16927530, usage_count = 16927537, ds_tvb 
 0x1024b38, used_in = 0x1024b3f = {0x14244489, <error reading variable>
> (on some occassions, the tvb address was not accessible at all)
> continue -> segfault when the illegal pointer is dereferenced
> The crash only happens when a display filter is set before the capture
 file is loaded.
> I was not able to reproduce the crash on Debian Lenny.
> Wireshark doesn't crash if I delete the last packet (number 65) from the
 pcap file. It also doesn't crash if any other file is loaded before
 loading crash5.pcap.
> Any idea what's going wrong or what I can do to track this down?
__________________________________________________________________________
ent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
rchives:    http://www.wireshark.org/lists/wireshark-dev
nsubscribe: https://wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe