Rather than requiring all callers to pass a non-null source argument,
explicitly allow a NULL source when the size is zero. This is consistent
with g_memdup behavior.
While at it, fix a memleak and avoid memset(0,0,0) in tests.
Change-Id: I86a092625a508544d180da959e4afdd0366539f4
Reviewed-on: https://code.wireshark.org/review/26496
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Mališa Vučinić <malishav@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Evan Huus <eapache@gmail.com>
Change-Id: I2943c67238fb913258f0f1f15df968c17b1ea002
Reviewed-on: https://code.wireshark.org/review/25626
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
There are cases where wmem_tree needs to know its number of nodes.
Change-Id: I6411cf4275fd4d85a1d76382e1922d236be3b176
Reviewed-on: https://code.wireshark.org/review/20005
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
This mimics the function g_list_insert_sorted.
Change-Id: I6f7ac01155588006662c8c0c138d88cea753868c
Reviewed-on: https://code.wireshark.org/review/19978
Reviewed-by: Dario Lombardo <lomato@gmail.com>
This can be used similarly to wmem_tree_new_autoreset for hash tables that need
reset after capture file change.
Change-Id: I3a2f0b0a0cad3eca46266523c594d3d7aac17489
Reviewed-on: https://code.wireshark.org/review/19794
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: Evan Huus <eapache@gmail.com>
Also, fix identation - tab stops are set every 8 spaces, not every 4
spaces, in UN*X, which is why the mode lines specify that.
Change-Id: If7cfc2cdae26feb2d5c13e31a32ed950354fb15b
Reviewed-on: https://code.wireshark.org/review/16789
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The system, GLib, and wmem string functions can perform differently,
particularly on Windows. Start adding performance tests to wmem_test so
that we can see the differences.
With this change applied "wmem_test --verbose" prints out the following
on a Windows 7 x64 VM here. wmem_test is linked against GLib 2.4.20.
(MINPERF:g_printf_string_upper_bound (via g_snprintf) 1 string: u 327.602 ms s 0
.000 ms)
(MINPERF:g_printf_string_upper_bound (via g_snprintf) 5 strings: u 1419.609 ms s
0.000 ms)
(MINPERF:g_printf_string_upper_bound (via g_snprintf) mixed args: u 1606.810 ms
s 0.000 ms)
(MINPERF:_snprintf_s upper bound 1 string: u 124.801 ms s 0.000 ms)
(MINPERF:_snprintf_s upper bound 5 strings: u 140.401 ms s 0.000 ms)
(MINPERF:_snprintf_s upper bound mixed args: u 124.801 ms s 0.000 ms)
(MINPERF:g_strdup_printf 2 strings: u 702.005 ms s 0.156 ms)
(MINPERF:g_strconcat 2 strings: u 78.000 ms s 0.000 ms)
(MINPERF:g_strdup_printf 5 strings: u 1419.609 ms s 0.156 ms)
(MINPERF:g_strconcat 5 strings: u 93.601 ms s 0.156 ms)
(MINPERF:wmem_strdup_printf 2 strings: u 343.202 ms s 0.312 ms)
(MINPERF:wmem_strconcat 2 strings: u 93.601 ms s 0.468 ms)
(MINPERF:wmem_strdup_printf 5 strings: u 327.602 ms s 8.268 ms)
(MINPERF:wmem_strconcat 5 strings: u 62.400 ms s 3.432 ms)
Change-Id: Id9b23918829db1719d141e7f830b9eba6245a25b
Reviewed-on: https://code.wireshark.org/review/14857
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Makes wmem_map more similar to g_hash.
Change-Id: Ia17a19ab0be8e07fbb64801d54db2ba8217a7fea
Reviewed-on: https://code.wireshark.org/review/15020
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Makes wmem_list more similar to glib lists.
Change-Id: Ifadf0627791a72c4118a14f205aa1a7189894d27
Reviewed-on: https://code.wireshark.org/review/15019
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Adds options that control depth of MPTCP analysis, notably:
- if mptcp_relative_seq is enabled, can display relative MPTCP sequence
numbers
- if mapping analysis is allowed, can tell in which packets the DSS
mappings covering this data was sent
- if intersubflow checks are enabled, it can check for retransmissions
over other subflows
Change-Id: I82b934513c9f16affb60c066a1fbcca234ffc999
Reviewed-on: https://code.wireshark.org/review/12316
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
This change makes wmem_array more similar to GArray by adding
two functions that mimic the first two params of g_array_new().
Change-Id: Iaec999cd2e44f79f44d766be5d39741b73602e5a
Reviewed-on: https://code.wireshark.org/review/13989
Petri-Dish: Evan Huus <eapache@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Evan Huus <eapache@gmail.com>
We crank up pedantic warnings enough that this provokes "warning: ISO
C90 forbids mixed declarations and code" on the OS X 10.5 buildbot.
Change-Id: Ic3962f20d85e3ed003b84b298f83d12c3ae25ea1
Reviewed-on: https://code.wireshark.org/review/12120
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Interval trees (wmem_itree_t) are implemented as an extension of wmem_tree with a
guint64-based range as the key.
This is useful for instance in MPTCP analysis, to look for packets
matching a range defined by a mapping across TCP subflows.
Change-Id: Iea706d44fe975e390a4191ad0257ef37d5c71525
Reviewed-on: https://code.wireshark.org/review/11714
Reviewed-by: Evan Huus <eapache@gmail.com>
Petri-Dish: Evan Huus <eapache@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Guy Harris <guy@alum.mit.edu>
accept the node key as a first parameter.
wmem_tree accepts all sort of keys (strings, integers, soon ranges),
thus it is of interest for various purposes (testing, greedy search) to
know the key of the node.
Change-Id: Ie748b917bef91f0b1ba8cce15bd1b471922641dc
Reviewed-on: https://code.wireshark.org/review/11683
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Evan Huus <eapache@gmail.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Some of the allocators are close enough that a little bit of system load at the
time of the test was enough to throw them off, and it was causing unnecessary
buildbot failures. Benchmarking on real-world cases at the time of
implementation (as well as reliable "average" results on the buildbots) has left
me confident that block_fast is, in fact, faster than block, which is faster
than simple/strict.
Additionally, the allocators are effectively "done" and unlikely to change, so
the possibility of uncaught performance regressions is low.
Change-Id: I144ea4cd9d6000edc4075ed682ce6a4aeaf5e28a
Reviewed-on: https://code.wireshark.org/review/3356
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Apparently the new win8 vm has a *very* low-resolution timer, and the allocators
are indistinguishable at the previous amount of work.
Change-Id: If4e5bb8f85b1f0d39658f54001c88f42ffddfc47
Reviewed-on: https://code.wireshark.org/review/2768
Reviewed-by: Evan Huus <eapache@gmail.com>
As it turns out, we do occasionally need it.
Bug:10115
Change-Id: Ifec79e4d2470bbc09f15674534d01418a6571a0d
Reviewed-on: https://code.wireshark.org/review/1688
Reviewed-by: Evan Huus <eapache@gmail.com>
As Jakub pointed out, our +1/-1 logic for null terminators wasn't quite right.
Also be sure to re-copy the va_list parameter if we need to re-use it, as
otherwise things break oddly.
Change-Id: Ibeaa95af602f565791e9378a6cfce434f13025eb
Reviewed-on: https://code.wireshark.org/review/1670
Reviewed-by: Evan Huus <eapache@gmail.com>
It appears that on some platforms the timer underlying g_test_timer() is
relatively low-precision, so the small amount of work that we were previously
doing was not enough for the timer to provide a useful value.
Bumping the amount of work should provide more meaningful values, and the whole
timing step still takes only a few seconds.
Change-Id: Idce1386eaa33add845d9a2758b0beb72bbf370d6
Reviewed-on: https://code.wireshark.org/review/1523
Reviewed-by: Evan Huus <eapache@gmail.com>
Follow-up to g19e650f43adf23b0aa92821bff0cc389643944f6 since the fuzz-bot is
still failing.
Change-Id: I2d05a861b0edf50ce734b682e6e3e33729bf6771
Reviewed-on: https://code.wireshark.org/review/1503
Reviewed-by: Evan Huus <eapache@gmail.com>
I believe the XP buildbot failures are simply running out of memory, so
hopefully reducing the number of iterations should be enough to let it finish
reliably.
Change-Id: I40af789d528c2623e95f153529205b5e617c6e02
Reviewed-on: https://code.wireshark.org/review/1496
Reviewed-by: Evan Huus <eapache@gmail.com>
For packet-scope allocation, there's no need to support realloc(), free()
cause memory will be garbage collected after packet dissection.
(and this allocator is much faster than full block allocator).
Change-Id: I73fdf708c3077f48f55bdcc71f4fa859e4ac2335
Reviewed-on: https://code.wireshark.org/review/1428
Reviewed-by: Anders Broman <a.broman58@gmail.com>
We now have to call wmem_init in order to randomly seed the values for wmem_map.
This means we can no longer rely on the lack of override, so we have to force
the right allocator type when testing/timing the allocators themselves.
Change-Id: I005034465b0a98f19876899b96ef65b3e4b1d759
Reviewed-on: https://code.wireshark.org/review/1468
Reviewed-by: Anders Broman <a.broman58@gmail.com>
This has two expected uses:
- Many current users of wmem_tree don't actually need the predecessor lookup
it provides (the lookup_le function family). A hash map provides straight
insertion and lookup much more efficiently than a wmem_tree when predecessor
lookup isn't needed.
- Many current users of glib's hash table and hash functions use untrusted data
for keys, making them vulnerable to algorithmic complexity attacks. Care has
been taken to make this implementation secure against such attacks, so it
should be used whenever data is untrusted.
In my benchmarks it is measurably slower than GHashTable, but not excessively
so. Given the additional security it provides this seems like a reasonable
trade-off (and it is still faster than a wmem_tree).
Change-Id: I2d67a0d06029f14c153eaa42d5cfc774aefd9918
Reviewed-on: https://code.wireshark.org/review/1272
Reviewed-by: Evan Huus <eapache@gmail.com>
C90 permits plain %f for doubles. Thanks to Alexis for pointing this out.
Change-Id: I3f927b0a50e5764c2297c7f9d680c6363ba9fd0e
Reviewed-on: https://code.wireshark.org/review/1073
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
There is confusion about API usage, and problems on my part concerning whether
keys should be compared signed or unsigned, and how to do that efficiently.
Unsigned keys in particular were behaving oddly.
Change-Id: I075693bbd04c15f79f24f9a24006003a914cc572
Reviewed-on: https://code.wireshark.org/review/924
Reviewed-by: Evan Huus <eapache@gmail.com>
This is a tree implementation intended to replace the current red-black tree in
wmem_tree (which was inherited from emem), assuming there are no regressions.
Splay trees bubble recently accessed keys to the top, and as such have a number
of very nice properties: https://en.wikipedia.org/wiki/Splay_tree
This implementation is a variant known as "independent semi-splaying", which has
better practical performance. It should do about as well as the red-black tree
for random insertions and accesses, but somewhat better for patterned accesses
(such as accessing each key in order, or accessing certain keys very
frequently).
There are a few other changes relative to the red-black tree implementation that
are worth mentioning:
- Instead of requiring complex keys to be split into guint32 chunks and doing
this weird trick with sub-trees, I let the keys be arbitrary pointers and
allowed the user to specify an arbitrary comparison function. If the function
is NULL then the pointers are compared directly for the simple integer-key
case.
- Splay trees do not need to store a red-black colour flag for each node. It is
also much easier to do without the parent pointer in each node. And due to
the simpler system for complex keys, I was able to remove the "is_subtree"
boolean. As such, splay nodes are 12 bytes smaller on 32-bit platforms, and
16 bytes smaller on a 64-bit platform.
All done in about half the lines of code.
Change-Id: I89fb57e07d2bb7e3197190c7c2597b0c5adcc03b
Reviewed-on: https://code.wireshark.org/review/758
Reviewed-by: Evan Huus <eapache@gmail.com>
(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>
WIRESHARK_DEBUG_WMEM_OVERRIDE environment variable once in wmem_init, not every
time wmem_allocator_new is called. We currently create a new pinfo pool for
every packet we dissect, so this is a small performance win, especially when
getenv is slow (which may happen if a large number of environment variables are
set, such as when fuzz-testing).
svn path=/trunk/; revision=52634
a NULL allocator. This gives us a single, central place to handle out-of-memory
errors (by, for example, throwing an exception) for basically all of epan.
The only remaining glib memory that is directly allocated is for the hash tables
used by the simple and strict allocators.
svn path=/trunk/; revision=51627
header later causes it to be redefined - as happens on my Solaris 11
virtual machine - we get a redefinition warning, which gets treated as
an error.
svn path=/trunk/; revision=51344
to override that to simple for valgrinding (we still force the allocator in the
allocator and timing tests, of course).
svn path=/trunk/; revision=50971
The overhead is not large, and it makes append much faster (O(1) vs O(n)).
It also will make a queue easy to add, which I need for a dissector I'm
writing...
svn path=/trunk/; revision=50744
Peter Wu