ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-bugs: [Wireshark-bugs] [Bug 9949] Buildbot crash output: fuzz-2014-04-02-29441.pcap

Date: Sat, 19 Apr 2014 11:12:36 +0000

Comment # 9 on bug 9949 from
The se_ allocation was introduced in

commit 1108352f008b3fb0e53c56110edc71af507734b0
Author: Anders Broman <[email protected]>
Date:   Fri Aug 21 10:12:47 2009 +0000

    Use col_text in frame data.
    - colum-utils needs more work, based on
     Didier Gautherons optimizations patch
http://wiki.wireshark.org/Development/Optimization

    svn path=/trunk/; revision=29489

and that dates back before we used a GtkTreeView for the packet list. 
Switching to a GtkTreeView, with a custom generate-the-column-text-as-needed
model, reduced the memory usage of the column list, but I think the columns all
still might get generated at least once, so it'd still have to turn addresses
to strings.

So I think the bottom line is that we don't need to se_ allocate the strings. 
Perhaps with all of Didier's changes - or, at least, his modified version of
the old GtkClist - the strings didn't just leak away, and could be generated
once and never re-generated for the address columns of all the rows, but I
don't think that's the case in our current code.

See

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

for a change to get rid of the se_ allocation in col_set_addr().

(It might be interesting to see whether caching the address strings even if
we're not resolving names speeds things up significantly without chewing up an
unacceptable amount of memory; I guess a capture with a billion different IP
addresses might be a worst-case example for this, but typical captures probably
have a *lot* fewer addresses, and if we ever have a problem with that, we could
treat it as a full-blown cache by keeping a usage count for addresses and
limiting the number that we cache by purging ones that have only appeared a few
times.)


You are receiving this mail because:
  • You are watching all bug changes.