tvb_uncompress initially allocates an output buffer of twice the
input size. It is typical to have a compression ratio of 2:1 or
5:1, but in the extreme case (lots of all identical bytes), 1030:1
is possible.
When extending the output buffer, instead of always malloc'ing
a new buffer and memcpy'ing the old buffer into it, call realloc,
which at least some (most?) of the time will extend the current
buffer in place instead. This should reduce the time to unzip
from always O(N^2) (where N is the compression ratio) to something
average case more like O(N) or O(N log N), depending on how often
it actually copies the data. It only really affects pathological
cases.
Related to #13779.
Experience has shown that:
1. The current logging methods are not very reliable or practical.
A logging bitmask makes little sense as the user-facing interface (who
would want debug but not crtical messages for example?); it's
computer-friendly and user-unfriendly. More importantly the console
log level preference is initialized too late in the startup process
to be used for the logging subsystem and that fact raises a number
of annoying and hard-to-fix usability issues.
2. Coding around G_MESSAGES_DEBUG to comply with our log level mask
and not clobber the user's settings or not create unexpected log misses
is unworkable and generally follows the principle of most surprise.
The fact that G_MESSAGES_DEBUG="all" can leak to other programs using
GLib is also annoying.
3. The non-structured GLib logging API is very opinionated and lacks
configurability beyond replacing the log handler.
4. Windows GUI has some special code to attach to a console,
but it would be nice to abstract away the rest under a single
interface.
5. Using this logger seems to be noticeably faster.
Deprecate the console log level preference and extend our API to
implement a log handler in wsutil/wslog.h to provide easy-to-use,
flexible and dependable logging during all execution phases.
Log levels have a hierarchy, from most verbose to least verbose
(debug to error). When a given level is set everything above that
is also enabled.
The log level can be set with an environment variable or a command
line option (parsed as soon as possible but still later than the
environment). The default log level is "message".
Dissector logging is not included because it is not clear what log
domain they should use. An explosion to thousands of domains is
not desirable and putting everything in a single domain is probably
too coarse and noisy. For now I think it makes sense to let them do
their own thing using g_log_default_handler() and continue using the
G_MESSAGES_DEBUG mechanism with specific domains for each individual
dissector.
In the future a mechanism may be added to selectively enable these
domains at runtime while trying to avoid the problems introduced
by G_MESSAGES_DEBUG.
Replace most instances of ws_debug_printf() except in
epan/dissectors and dissector plugins.
Some replacements use printf(), some use ws_debug(), and
some were removed because they were dead or judged to be
temporary.
Change all wireshark.org URLs to use https.
Fix some broken links while we're at it.
Change-Id: I161bf8eeca43b8027605acea666032da86f5ea1c
Reviewed-on: https://code.wireshark.org/review/34089
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Found by clang-tidy.
Change-Id: Iaf6cf84c33b03ddfcd39a333b49f4987002afa56
Reviewed-on: https://code.wireshark.org/review/31338
Petri-Dish: Dario Lombardo <lomato@gmail.com>
Petri-Dish: Guy Harris <guy@alum.mit.edu>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Negative lengths and empty buffers are not uncompressable, reject them.
A buffer overrun (read) could occur otherwise due to unsigned "avail_in"
becoming insanely large.
Bug: 14675
Change-Id: I20b686cc6ad6ef8a8d1975ed3d2f52c8eb1f1c76
Link: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7166
Reviewed-on: https://code.wireshark.org/review/27561
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
g_malloc() may abort(3) the program when the comprlen is insanely large so use tvb_memdup() instead.
Change-Id: I23fbdc2362900030c41da1c297ab0c787de7c5ca
Reviewed-on: https://code.wireshark.org/review/18043
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Many of the complaints from checkAPI.pl for use of printf are when its embedded
in an #ifdef and checkAPI isn't smart enough to figure that out.
The other (non-ifdef) use is dumping internal structures (which is a type of
debug functionality)
Add a "ws_debug_printf" macro for printf to pacify the warnings.
Change-Id: I63610e1adbbaf2feffb4ec9d4f817247d833f7fd
Reviewed-on: https://code.wireshark.org/review/16623
Reviewed-by: Michael Mann <mmann78@netscape.net>
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
the same mechanism as described in
7c40de5c38ac71323455c51dcc14a5eb385ce718
could trick us into using the wrong config.h
fix this for some occassions where config.h is included before we
include zlib.h
I saw compile errors on windows where we picked up config.h from a linux
build and zlib failed because of a mission unistd.h
Change-Id: I91cf73b96c9e1b6f009fb2376fabfe973d1ac941
Reviewed-on: https://code.wireshark.org/review/15874
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Change-Id: I0e845668a1b9dbec93ea920a8585ecfe60f001d1
Reviewed-on: https://code.wireshark.org/review/15044
Reviewed-by: Michael Mann <mmann78@netscape.net>
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
ZLIB_CONST must be defined before including zlib.h to expose z_const,
*AND* z_const shouldn't be used unless it's defined, because older
versions of zlib don't define it even if you define ZLIB_CONST.
While we're at it, throw in some DIAG_OFF(cast-qual)/DIAG_ON(cast-qual)
pairs to suppress unavoidable "cast throws away const qualification"
warnings.
The original "make zlib constness-aware" change also removed an
unnecessary include of <zlib.h> from wiretap/wtap.c, so we do that as
well.
Change-Id: I3c5269a8fbc54bbbb4d316544cc7b8fa30614c19
Reviewed-on: https://code.wireshark.org/review/12675
Petri-Dish: Guy Harris <guy@alum.mit.edu>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Guy Harris <guy@alum.mit.edu>
This reverts commit fb0246c6fd. That commit assumes that if you define Z_CONST, z_const will be defined; that is *not* the case with older versions of zlib, which don't define z_const under any circumstances.
Change-Id: I6f9b7ea18922799b1aaf94dc2c63120128f2550a
Reviewed-on: https://code.wireshark.org/review/12671
Reviewed-by: Guy Harris <guy@alum.mit.edu>
ZLIB_CONST must be defined before including zlib.h to expose 'z_const'.
Change-Id: Ic0dbd59ed3c760dd84ef4546f6ff4d5d3db91519
Reviewed-on: https://code.wireshark.org/review/12547
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
After updating next_in (to remove the gzip header), avail_in must also
be updated. Failing to do makes zlib read past the input buffer. In
theory this would resukt in a buffer overrun of at most double the input
length, in practice zlib returns as soon as the compression fails (after
reading a few bytes).
Bug: 11548
Change-Id: If71691a2846338f46d866964a77cc4e74a9b61dd
Reviewed-on: https://code.wireshark.org/review/12038
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
it consists of two bytes xsize + xsize bytes of data
use an unsigned type for xsize
fail gracefully if the field is present but truncated
tvb_length_remaining > tvb_captured_length_remaining
Change-Id: I7f5138743c2d88abdd4f5f18d3c0292612ddb559
Reviewed-on: https://code.wireshark.org/review/5654
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Change-Id: Ie64573f5a0b6e921a5011e487eea8e55f72b9a0b
Reviewed-on: https://code.wireshark.org/review/5653
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
Tested-by: Martin Kaiser <wireshark@kaiser.cx>
different value to them
Change-Id: I719db9180b2ba5f21653086f2697ca9bac68d6b1
Reviewed-on: https://code.wireshark.org/review/5652
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
Tested-by: Martin Kaiser <wireshark@kaiser.cx>
Bug: 10757
Change-Id: I30054c4a75ec86ea603cf78b702be5255c35f549
Reviewed-on: https://code.wireshark.org/review/5642
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
Tested-by: Martin Kaiser <wireshark@kaiser.cx>
(Using sed : sed -i '/^ \* \$Id\$/,+1 d')
Fix manually some typo (in export_object_dicom.c and crc16-plain.c)
Change-Id: I4c1ae68d1c4afeace8cb195b53c715cf9e1227a8
Reviewed-on: https://code.wireshark.org/review/497
Reviewed-by: Anders Broman <a.broman58@gmail.com>
John Thacker