https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16692
--- Comment #2 from Guy Harris <ghar...@sonic.net> ---
(In reply to Guy Harris from comment #1)
> This is a bit weird.
> This *might* be an issue with the capture filter check. Libpcap doesn't
> have a "check this filter's correctness asynchronously" option, because it
> does synchronous host name lookups (using the standard UN*X/Windows name
> resolution APIs); as I remember, we hand the check off to another thread, so
> it can proceed in the background and not stall user input.
>
> Perhaps if a capture is started at the wrong point in that process, it
> doesn't get applied.
I'm seeing behavior similar to the Windows behavior with:
Version 3.2.3 (Git v3.2.3 packaged as 3.2.3-1)
Copyright 1998-2020 Gerald Combs <ger...@wireshark.org> and contributors.
License GPLv2+: GNU GPL version 2 or later
<https://www.gnu.org/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.12.8, with libpcap, with POSIX capabilities
(Linux), with libnl 3, with GLib 2.64.2, with zlib 1.2.11, with SMI 0.4.8, with
c-ares 1.15.0, with Lua 5.2.4, with GnuTLS 3.6.13 and PKCS #11 support, with
Gcrypt 1.8.5, with MIT Kerberos, with MaxMind DB resolver, with nghttp2 1.40.0,
with brotli, with LZ4, with Zstandard, with Snappy, with libxml2 2.9.10, with
QtMultimedia, without automatic updates, with SpeexDSP (using system library),
with SBC, with SpanDSP, without bcg729.
Running on Linux 5.4.0-40-generic, with Intel(R) Core(TM) i9-9980HK CPU @
2.40GHz (with SSE4.2), with 7934 MB of physical memory, with locale
en_US.UTF-8, with light display mode, without HiDPI, with libpcap version 1.9.1
(with TPACKET_V3), with GnuTLS 3.6.13, with Gcrypt 1.8.5, with brotli 1.0.7,
with zlib 1.2.11, binary plugins supported (18 loaded). Built using gcc 9.3.0.
on Ubuntu 20.04.
This rules out my first hypothesis, that it's a difference between the Glib
implementation of threading atop Windows threads and the Glib implementation of
threading atop pthreads, as all UN*X implementations, as far as I know, are
atop pthreads, so the same behavior would show up in macOS and Linux under that
hypothesis.
--
You are receiving this mail because:
You are watching all bug changes.
___________________________________________________________________________
Sent via: Wireshark-bugs mailing list <wireshark-bugs@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
