/usr/bin/wireshark:11:wtap_seek_read:cf_read_record_r:cf_read_record:rescan_packets:cf_filter_packets

[errors.ubuntu.com bug bridge]

The Ubuntu Error Tracker has been receiving reports about a problem regarding wireshark. This problem was most recently seen with package version 2.4.5-1, the problem page at https://errors.ubuntu.com/problem/c807cd7bdb2b284a6289e17fd36806e579b90ad3 contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports.
If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://forms.canonical.com/reports/.

[Mikael Kanstrup (kanstrup)]

Build Information:
Wireshark 2.3.0 (v2.3.0rc0-3070-g7c3c15a)

Copyright 1998-2017 Gerald Combs <email address hidden> and contributors.
License GPLv2+: GNU GPL version 2 or later <http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
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 (64-bit) with Qt 5.5.1, with libpcap, with POSIX capabilities (Linux),
with libnl 3, with GLib 2.48.2, with zlib 1.2.8, with SMI 0.4.8, with c-ares
1.10.0, with Lua 5.2.4, with GnuTLS 3.4.10, with Gcrypt 1.6.5, with MIT
Kerberos, with GeoIP, with nghttp2 1.7.1, with LZ4, with Snappy, with
QtMultimedia, without AirPcap, with SBC, with SpanDSP.

Running on Linux 4.8.0-41-generic, with Intel(R) Xeon(R) CPU E5-1650 v2 @
3.50GHz (with SSE4.2), with 24038 MB of physical memory, with locale
en_US.UTF-8, with libpcap version 1.7.4, with GnuTLS 3.4.10, with Gcrypt 1.6.5,
with zlib 1.2.8.

Built using gcc 5.4.0 20160609.

--
Two different crashes observed but use case are quite similar and call stacks indicate root cause might be same so reporting them as one.

The use cases are like this:

Crash #1

1. Capture or open a big capture file.
2. Save capture file
3. While save file operation is ongoing..
4. Open "Capture Options" dialog
5. Start new capture
6. Crash observed.

Crash #2

1. Capture or open a big capture file.
2. Set a display filter
3. While rescanning is ongoing..
4. Open "Capture Options" dialog
5. Start new capture
6. Crash observed.

The use case is perhaps a bit odd but it has happened to me by accident a number of times as the UI allows it.

Crash #1 - Start capture while saving capture file...

Thread 1 "wireshark" received signal SIGSEGV, Segmentation fault.
wtap_seek_read (wth=0x0, seek_off=228115028, phdr=phdr@entry=0x7fffffffc690, buf=buf@entry=0x7fffffffc670, err=err@entry=0x7fffffffc5cc,
    err_info=err_info@entry=0x7fffffffc5d0) at wtap.c:1403
1403 phdr->pkt_encap = wth->file_encap;
(gdb) bt
#0 wtap_seek_read (wth=0x0, seek_off=228115028, phdr=phdr@entry=0x7fffffffc690, buf=buf@entry=0x7fffffffc670, err=err@entry=0x7fffffffc5cc,
    err_info=err_info@entry=0x7fffffffc5d0) at wtap.c:1403
#1 0x000000000047fe15 in cf_read_record_r (cf=cf@entry=0xc83ce0 <cfile>, fdata=fdata@entry=0xaad1220, phdr=phdr@entry=0x7fffffffc690,
    buf=buf@entry=0x7fffffffc670) at file.c:1502
#2 0x0000000000480aea in process_specified_records (cf=cf@entry=0xc83ce0 <cfile>, range=range@entry=0x0, string1=string1@entry=0x79e74c "Saving",
    string2=string2@entry=0x79d1d4 "packets", callback=callback@entry=0x47e2e0 <save_record>, callback_args=callback_args@entry=0x7fffffffc8d0,
    show_progress_bar=1, terminate_is_stop=1) at file.c:2058
#3 0x000000000048343f in cf_save_records (cf=cf@entry=0xc83ce0 <cfile>, fname=0x1115df38 "/home/CORPUSERS/23047419/big-sniff4.pcapng.gz",
    save_format=save_format@entry=2, compressed=compressed@entry=1, discard_comments=discard_comments@entry=0, dont_reopen=dont_reopen@entry=0)
    at file.c:4560
#4 0x00000000004b25c8 in MainWindow::saveAsCaptureFile (this=0xefb9b0, cf=0xc83ce0 <cfile>, must_support_comments=mu...

[Peter Wu (lekensteyn)]

Confirmed case 2 with v2.9.0rc0-1112-g1108791d29. Quick reproducer:

randpkt -c 10000 large.pcap
wireshark -r large.pcap -i dbus-session
# press Ctrl-E to start the capture

Depending on the timing, it shows a dialog and then crashes after closing the dialog (with a different top stack though) or it shows:

wiretap/wtap.c:1370:15: runtime error: member access within null pointer of type 'wtap' (aka 'struct wtap')
    #0 0x7fe89dcc56e5 in wtap_get_rec wiretap/wtap.c:1370:15
    #1 0x55fb8ff7b0a9 in read_record file.c:1152:23
    #2 0x55fb8ff78fab in cf_read file.c:619:7
    #3 0x55fb901f1bff in MainWindow::openCaptureFile(QString, QString, unsigned int, int) ui/qt/main_window_slots.cpp:246:17
    #4 0x55fb9003363d in main ui/qt/main.cpp:831:21
    #5 0x7fe89c5ce06a in __libc_start_main (/usr/lib/libc.so.6+0x2306a)
    #6 0x55fb8fe57659 in _start (run/wireshark+0xf4f659)

wiretap/wtap.c:1376:9: runtime error: member access within null pointer of type 'wtap' (aka 'struct wtap')
    #0 0x7fe89dcc5745 in wtap_get_buf_ptr wiretap/wtap.c:1376:9
    #1 0x55fb8ff7b1ad in read_record file.c:1153:23
    #2 0x55fb8ff78fab in cf_read file.c:619:7
    #3 0x55fb901f1bff in MainWindow::openCaptureFile(QString, QString, unsigned int, int) ui/qt/main_window_slots.cpp:246:17
    #4 0x55fb9003363d in main ui/qt/main.cpp:831:21
    #5 0x7fe89c5ce06a in __libc_start_main (/usr/lib/libc.so.6+0x2306a)
    #6 0x55fb8fe57659 in _start (run/wireshark+0xf4f659)

[Peter Wu (lekensteyn)]

*** Bug 14351 has been marked as a duplicate of this bug. ***

[Peter Wu (lekensteyn)]

The "Crash #2" scenario is caused by handling the "startCapture" action while the original file is still being read:
#4 0x00005555565c16ce in cf_close file.c:361
#5 0x000055555686e564 in MainWindow::startCapture ui/qt/main_window_slots.cpp:848
#6 0x00005555568be177 in MainWindow::on_actionCaptureStart_triggered ui/qt/main_window_slots.cpp:3582
...
#23 0x00005555569cb97d in update_progress_dlg ui/qt/progress_frame.cpp:77
#24 0x00005555565c567b in cf_read file.c:609
#25 0x000055555683ec10 in MainWindow::openCaptureFile ui/qt/main_window_slots.cpp:246
#26 0x000055555668064e in main ui/qt/main.cpp:831

The "Crash #1" scenario occurs for a similar reason:
#4 0x5555565c23fa in cf_close file.c:395:5
#5 0x5555566cf099 in MainWindow::testCaptureFileClose ui/qt/main_window.cpp:1874:13
#6 0x5555568be0c9 in MainWindow::on_actionCaptureStart_triggered ui/qt/main_window_slots.cpp:3581:9
...
#23 0x5555569cb97c in update_progress_dlg ui/qt/progress_frame.cpp:77:5
#24 0x5555565d8271 in process_specified_records file.c:2074:7
#25 0x5555565f35a9 in cf_save_records file.c:4426:13
#26 0x5555566d908d in MainWindow::saveAsCaptureFile ui/qt/main_window.cpp:1457:18
#27 0x555556883802 in MainWindow::on_actionFileSaveAs_triggered ui/qt/main_window_slots.cpp:1696:5

The root cause for these issues:
- While a file is being loaded or scanned, the progress dialog is updated.
- That causes Qt to process events/signals (such as opening a new file).
- The capture file is closed even though it is stll being processed (cf_read or process_specified_records).
(Note the similarity with bug 10870, it cf_close's the file indirectly through cf_open though)

[Gerrit-do-not-reply (gerrit-do-not-reply)]

Change 28541 had a related patch set uploaded by Peter Wu:
Qt: fix crash on changing capture file while loading a previous one

https://code.wireshark.org/review/28541

[Gerrit-do-not-reply (gerrit-do-not-reply)]

Change 28541 merged by Anders Broman:
Qt: fix crash on opening a capture file while loading/saving another

https://code.wireshark.org/review/28541

[Gerrit-do-not-reply (gerrit-do-not-reply)]

Change 28578 had a related patch set uploaded by Peter Wu:
Qt: fix crash on opening a capture file while loading/saving another

https://code.wireshark.org/review/28578

[Gerrit-do-not-reply (gerrit-do-not-reply)]

Change 28578 merged by Peter Wu:
Qt: fix crash on opening a capture file while loading/saving another

https://code.wireshark.org/review/28578

[Peter Wu (lekensteyn)]

Fixed the crashes in:
v2.9.0rc0-1153-g536e26c55e
v2.6.2rc0-130-gc1fb20adc7

Note: there might be some interaction glitches (e.g. file open actions that are ignored), but not crashing should already be an improvement on itself.

[Peter Wu (lekensteyn)]

According to https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13594 this has been fixed in:
v2.9.0rc0-1153-g536e26c55e
v2.6.2rc0-130-gc1fb20adc7

As long as people enable the security or -updates repo, they should have at least Wireshark 2.6.8 which has this fix incorporated.