for FT_UINT_STRINGs and FT_UINT_BYTEs is still in the TVB. Any infinite loop
that adds a counted field ought to be extracting the length for its own offset
anyways, in which case it will overflow on the next iteration and won't actually
loop forever.
svn path=/trunk/; revision=52766
This time it makes more sense, cause for each dissection we need two wmem allocators.
Reseting wmem allocator is much faster than destroy & create.
svn path=/trunk/; revision=52706
proto_tree_add_item was valid *before* we short-circuited based on a NULL tree.
This was good in that it removed a common source of really-long-loop bugs. It
was less good in that it cost us about 8% in speed when doing a tree-less
dissection, but we decided the tradeoff was worth it.
After Anders' recent mail to -dev about performance, I started thinking about
how to optimize this. It occurred to me that the vast majority of the logic
involved in the check was dealing with the length value - fetching the actual
length if it was a counted string, calculating the length if it was -1, adding
the length to the offset in a way that was free from overflows, etc.
All of this is (theoretically) unnecessary - simply checking the offset without
worrying about the length will still catch the very-long-loops, since it is the
offset that increases in each iteration, not the length.
All that to justify:
- implement tvb_ensure_offset_exists which throws an exception if the offset is
not within the tvb
- use it instead of all the complicated other logic in the pre-short-circuit
step of proto_tree_add_item and friends
This gives us back about 3/4 of the performance we lost in the original patch.
We're still ~2% slower than without any check, but this is the best I can think
of right now.
svn path=/trunk/; revision=52578
tree_data and reference it directly when allocating/freeing tree items. This
lets us keep multiple around when we need them, and still lets us use
wmem_free_all for a major speedup. It also, coincidentally, lets us get rid of
the annoying fi_tmp hack that was needed before, since that element gets swept
up in the free_all with everything else.
Keep one pool cached to avoid creating/destroying a pool for each packet,
another minor performance win.
The various changes in approach seem to balance out pretty much exactly, this
still gives ~11% over pre-52569.
svn path=/trunk/; revision=52573
field_info separately. We still have to walk the tree in order to free certain
fvalues, but that's not a big deal. Another ~11% speed-up running "tshark -nVr"
on a large capture.
svn path=/trunk/; revision=52569
Even without making use of free_all (which should be possible) this still
results in ~8% speedup running "tshark -nVr" on a large file in my tests.
svn path=/trunk/; revision=52568
explicit, and frees up the "generic" names (like tvb_memdup) for new signatures
that take the appropriate wmem pool.
Majority of the conversion done with sed.
svn path=/trunk/; revision=52164
For those with dissectors outside the source tree, please see tools/convert_expert_add_info_format.pl for help with the conversion. Please do not use expert_add_info_format_internal, as it's support time will be very short lived.
svn path=/trunk/; revision=51844
- (for now) keep ABI, restore prototype of old proto_tree_add_item, add new proto_tree_add_item_new
- add few helpers for boolean, time, string which will do ->id
- don't use HFI_INIT directly, use it by another macro (MSVC has very small limit for section name)
svn path=/trunk/; revision=51401
overloaded use of the DISPLAY field). Thanks to Jakub for pointing out I'd done
this wrong the first time (months ago in r49357).
Fixes severity display for collectd protocol, originally filed at:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8472
svn path=/trunk/; revision=50935
