Application crash when re-enabling "Update list of packets in real time." option

This issue was migrated from bug 4035 in our old bug tracker.

Original bug information:

Reporter: Jeroen Sack
Status: CONFIRMED
Product: Wireshark
Component: Qt UI
OS: All
Platform: All
Version: Git

💬 Jeroen Sack said:

Build Information: Version 1.3.1-LFW113

Copyright 1998-2009 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 with GTK+ 2.16.6, with GLib 2.20.5, with WinPcap (version unknown), with libz 1.2.3, without POSIX capabilities, with libpcre 7.0, with SMI 0.4.8, with c-ares 1.6.0, with Lua 5.1, without Python, with GnuTLS 2.8.1, with Gcrypt 1.4.4, with MIT Kerberos, with GeoIP, with PortAudio V19-devel (built Sep 21 2009), with AirPcap, with new_packet_list.

Running on Windows XP Service Pack 3, build 2600, with WinPcap version 4.1 beta5 (packet.dll version 4.1.0.1452), based on libpcap version 1.0.0, GnuTLS 2.8.1, Gcrypt 1.4.4, without AirPcap.

Built using Microsoft Visual C++ 9.0 build 30729

Wireshark is Open Source Software released under the GNU General Public License.

Check the man page and http://www.wireshark.org for more information.

When changing option 'update list of packets in real-time' to not running and after that stopping the capture, the application crashes.

Also when turning it on while the capture is running crashes it. (break on wtap.c line 632 wth->phdr.pkt_encap = wth->file_encap; )

It also happens in the SVN release 30030.

added crash uiqt versiondev labels

💬 Kovarththanan Rajaratnam said:

I can't reproduce this one. Could someone else give it go?

Version 1.3.1 (SVN Rev 30056 from /trunk)

Copyright 1998-2009 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 with GTK+ 2.16.6, with GLib 2.20.5, with WinPcap (version unknown),
with libz 1.2.3, without POSIX capabilities, with libpcre 7.0, with SMI 0.4.8,
with c-ares 1.6.0, with Lua 5.1, without Python, with GnuTLS 2.8.1, with Gcrypt
1.4.4, with MIT Kerberos, with GeoIP, with PortAudio V19-devel (built Sep 21
2009), with AirPcap, with new_packet_list.

Running on Windows XP Service Pack 2, build 2600, with WinPcap version 4.1 beta5
(packet.dll version 4.1.0.1452), based on libpcap version 1.0.0, GnuTLS 2.8.1,
Gcrypt 1.4.4, without AirPcap.

Built using Microsoft Visual C++ 9.0 build 30729

Wireshark is Open Source Software released under the GNU General Public License.

Check the man page and http://www.wireshark.org for more information.

💬 Jeroen Sack said:

I just tried this again on my Macbook Pro with Snow Leopard and 1.2.2, and I still get a full crash.

I will describe what I do exactly again, because I think this should happen at every PC.

I start wireshark with all default settings, so real time capturing is on. Then I start capturing while I set 'preferences->capture->update list of packets in real time' to off. After this I click the stop capturing button the application stops responding and after a few seconds it shuts itself down.

Version 1.2.2 (SVN Rev 29910)

Copyright 1998-2009 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 with GTK+ 2.12.9, with GLib 2.16.3, with libpcap 1.0.0, with libz
1.2.3, without POSIX capabilities, with libpcre 7.8, with SMI 0.4.8, with c-ares
1.5.3, with Lua 5.1, with GnuTLS 2.6.2, with Gcrypt 1.4.3, with MIT Kerberos,
without GeoIP, with PortAudio V19-devel (built Nov 14 2008), without AirPcap.

Running on Darwin 10.0.0 (MacOS 10.6.1), with libpcap version 1.0.0, GnuTLS
2.6.2, Gcrypt 1.4.3.

Built using gcc 4.0.1 (Apple Inc. build 5488).

Wireshark is Open Source Software released under the GNU General Public License.

Check the man page and http://www.wireshark.org for more information.

💬 Stephen Fisher said:

I can reproduce it with my latest SVN build. It happens when toggling the display packets in real-time option on or off while capturing. I'll take a look at it. My build information:

wireshark 1.3.1 (SVN Rev 30154 from /trunk)

Copyright 1998-2009 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 with GTK+ 2.18.0, with GLib 2.22.0, with libpcap 0.9.5, with libz
1.2.3, without POSIX capabilities, with libpcre 7.8, with SMI 0.4.8, with c-ares
1.6.0, with Lua 5.1, without Python, with GnuTLS 2.6.3, with Gcrypt 1.4.1, with
MIT Kerberos, with GeoIP, with PortAudio V19-devel (built Dec 18 2008), without
AirPcap, with new_packet_list.

Running on Darwin 9.8.0 (MacOS 10.5.8), with libpcap version 0.9.5, GnuTLS
2.6.3, Gcrypt 1.4.1.

Built using gcc 4.0.1 (Apple Inc. build 5493).

💬 Stephen Fisher said:

Here's the error and backtrace from gdb:

ERROR:file.c:376:cf_reset_state: assertion failed: (cf->state != FILE_READ_IN_PROGRESS)

Program received signal SIGABRT, Aborted.
0x9340de42 in __kill ()
(gdb) where
#0  0x9340de42 in __kill ()
#1  0x9340de34 in kill$UNIX2003 ()
#2  0x9348023a in raise ()
#3  0x9348c679 in abort ()
#4  0x00ffaa32 in g_assertion_message (domain=0x102f0a0 "", file=0x0, line=0, func=0x101806 "cf_reset_state", message=0x1dd08f60 "ERROR:file.c:376:cf_reset_state: assertion failed: (cf->state != FILE_READ_IN_PROGRESS)") at gtestutils.c:1302
#5  0x00ffb0a8 in g_assertion_message_expr (domain=0x0, file=0x0, line=0, func=0x0, expr=0x0) at gtestutils.c:1313
#6  0x00013c62 in cf_reset_state (cf=<value temporarily unavailable, due to optimizations>) at file.c:376
#7  0x000142b4 in cf_open (cf=0x170560, fname=0x1ce65d40 "/var/folders/ZU/ZUiIzjCiHwO9OP0gVVwhLU+++TI/-Tmp-//wiresharkLfXEAsbvdv", is_tempfile=1, err=0xbfffe238) at file.c:283
#8  0x0000a685 in capture_input_read_all [inlined] () at capture.c:250
#9  0x0000a685 in capture_input_closed (capture_opts=0x1806e0) at capture.c:618
#10 0x0000e0d5 in sync_pipe_input_cb (source=13, user_data=0x1806e0) at capture_sync.c:1189
#11 0x0004d443 in pipe_input_cb (data=0x16ad04, source=13, condition=GDK_INPUT_READ) at gui_utils.c:690
#12 0x009fb567 in gdk_io_invoke (source=0x1ce59d80, condition=G_IO_IN, data=0x1ce5d990) at gdkevents.c:1080
#13 0x00fd492e in g_main_dispatch [inlined] () at gmain.c:1960
#14 0x00fd492e in g_main_context_dispatch (context=0x5e14f00) at gmain.c:2513
#15 0x00fd838b in g_main_context_iterate (context=0x5e14f00, block=1, dispatch=1, self=0x5e1c870) at gmain.c:2591
#16 0x00fd8677 in g_main_loop_run (loop=0x1ce48500) at gmain.c:2799
#17 0x005d77d1 in gtk_main () at gtkmain.c:1205
#18 0x00057505 in main (argc=0, argv=0xbffff628) at main.c:2745

💬 Anders Broman said:

Could you verify if the problem still exists on a recent SVN build? /Anders

💬 Jeroen Sack said:

I just compiled revision 31894 on windows, and the problem is still there.

💬 Gerald Combs said:

This also affects the 1.2 branch and possibly 1.0. I checked in a change in r33005 that should fix the problem. Jeroen, can you test it?

💬 Jeroen Sack said:

(In reply to comment #7)

This also affects the 1.2 branch and possibly 1.0. I checked in a change in r33005 that should fix the problem. Jeroen, can you test it?

I just realized that I totally forgot to test this, but it still crashes in 1.5.0 revision 34134.

💬 Christopher Maynard said:

(In reply to comment #8)

(In reply to comment #7)

This also affects the 1.2 branch and possibly 1.0. I checked in a change in r33005 that should fix the problem. Jeroen, can you test it?

I just realized that I totally forgot to test this, but it still crashes in 1.5.0 revision 34134.

And while looking at bug #6208 (closed), I encountered this as well, so the crash still happens with r38373.

💬 Christopher Maynard said:

(In reply to comment #9)

And while looking at bug #6208 (closed), I encountered this as well, so the crash still happens with r38373.

Hmm, actually that's not the case. Simply turning it on/off while capturing doesn't crash Wireshark for me, but it does cause bug #6208 (closed), except the displayed packet count was lower than the packet count in my case when they should both be the same.

The crash for me occurred with "Update list of packets in real time" disabled when a display filter was applied while capturing.

OK, so I think this bug can be closed now. Jeroen?

💬 Christopher Maynard said:

(In reply to comment #10)

OK, so I think this bug can be closed now. Jeroen?

Closing as fixed, tested with r38373 and r38385. Reopen if it happens again.

💬 Jeroen Sack said:

Just checked, its still not fixed.

The version I checked is revision 38606 autobuild as I don't have visual studio installed at the moment.

How I did it:

1. Fresh install wireshark
2. Turn off "update list of packets in real time"
3. start a capture session (you get a screen "with waiting for capture input data ...")
4. Turn "update list of packets in real time" back on
5. Wait for a packet to come in and see wireshark crash

💬 Evan Huus said:

Still happens in Qt UI.

💬 Michael Mann said:

I can still duplicate this in current master (1.99) using Jeroen's steps in comment #‍12.

I added some NULL checks, but all it seems to do is push the problem downstream. It doesn't seem like Wireshark is architected to change this preference during a live capture. A bunch of the capture_file structure members are NULL because we don't actually open a capture file (call cf_open) unless we are displaying. Doing it "midstream" of a capture doesn't yield good results.

💬 Peter Wu said:

Still reproducible with current master and master-2.6 (v2.9.1rc0-226-g30c90fa7 and v2.6.6rc0-60-g526d8529). Backtrace on master:

Thread 1 "wireshark" received signal SIGSEGV, Segmentation fault.
0x00007fffdc4ece2c in wtap_cleareof (wth=0x0) at wiretap/wtap.c:1251
1251            file_clearerr(wth->fh);
(gdb) bt
#0  0x00007fffdc4ece2c in wtap_cleareof (wth=0x0) at wiretap/wtap.c:1251
#1  0x000055555662a078 in cf_continue_tail (cf=0x555559cbd200 <cfile>, to_read=12, err=0x7fffffff83e0) at file.c:801
#2  0x00005555580b32bc in capture_input_new_packets (cap_session=0x616000004d28, to_read=12) at ui/capture.c:498
#3  0x00005555582193f5 in sync_pipe_input_cb (source=18, user_data=0x616000004d28) at capchild/capture_sync.c:1691
#4  0x0000555556884905 in MainWindow::pipeActivated (this=0x616000004b80, source=18) at ui/qt/main_window_slots.cpp:967

While re-enabling the option causes a crash, it does not seem to crash when toggling the option after a capture was started with the option enabled.

Merge with #14061 (closed) ?

mentioned in merge request !10994 (merged)

marked #14061 (closed) as a duplicate of this issue

marked this issue as related to #14061 (closed)

closed with commit 801554fb