Comment # 8
on bug 9296
from Michael Mann
(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.
> 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.
You are receiving this mail because:
- You are watching all bug changes.