Comment # 9
on bug 9296
from Evan Huus
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > (In reply to comment #5)
> > > The simplest fix, I
> > think, is to have dissector_add_string do a g_strdup of
> > > the key, and
> > subsequently free it either in dissector_delete_string or when
> > > the table
> > is destroyed at the end of the program (possibly by specifying a
> > > key
> > destructor function to g_hash_table_new_full). The annoying part is that
> > >
> > this wastes a little memory for the 99.9% of strings that are static on the
> > > > stack, but I can't think of anything else off the top of my head.
> > >
> >
> > > Other ideas are welcome :)
> >
> > I still think that using capture scope
> > memory in the lua wrapper is
> > "simpler". While I have seen dissectors
> > added/deleted during dissection
> > (closest I can come to a real world
> > example of your while loop), it's
> > usually done in the "handoff". And the
> > memory footprint is small enough
> > that I can live with it over punishing
> > all other dissectors (and overall
> > Wireshark memory) with the extra
> > allocations.
>
> > I'm OK with that, though I'm rather curious now how much the
> > difference would actually be if we strduped all of them - I don't know how
> > many strings we actually register by default.
>
> grep dissector_add_string. I get over 400 calls in the epan\dissectors
> directory. Admittedly, not all may be registered by default.
If we make it 500 calls and say 32 bytes each (though most are probably
shorter) that's still only 16KB of memory, which isn't really significant given
Wireshark's existing footprint.
> > I assume using se_ API
> > would be prefered as it needs to be backported?
>
> >Oh, actually it would have
> > to be epan-scope memory, since the same Lua plugin can persist across
> > multiple captures. Now I'm leaning towards towards strduping all of them
> > again...
>
> I'm begrudgingly starting to agree with you. I thought about just trying to
> keep the memory in Lua (internal array of strings or something), but I guess
> it's possible for a "regular" dissector to do this.
Ya, that's what I was thinking. And it means if some other sort of plugin like
wsgd wants to do something similar then they don't have to jump through hoops.
You are receiving this mail because:
- You are watching all bug changes.
