Wireshark-bugs: [Wireshark-bugs] [Bug 5203] Lua: Must expose pinfo.private_data as ByteArray of
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5203
--- Comment #3 from Stig Bjørlykke <stig@xxxxxxxxxxxxx> 2011-10-18 23:41:48 PDT ---
(In reply to comment #2)
> IMO, this new 'private' field is more trouble than it's worth (due to the
> potential bugs in the C glue), and there's not much value in passing around an
> array of strings.
How can it have little value when I need to pass around several strings/values
between different dissectors? The potential bugs in the C glue can be fixed,
will the trouble then go away?
> Lua affords us a different (and perhaps cleaner) way of
> achieving the same thing by creating a dictionary that uses a packet-unique
> field as a key (such as frame number).
How can I use this when passing strings between C dissectors? And between a C
dissector and a Lua dissector, and then to another Lua dissector? What about
if we want to use this solution in a Python dissector?
> 1. There's a memory leak at line 834. You're returning w/o freeing the string
> allocated a few lines before.
Sure, this is a bug. But will it ever happen?
> 2. PrivateTable:__gc (and some/all of the other garbage collectors in
> wslua_pinfo.c)
> Lua only calls __gc for an object right before it's about to collect that
> object,
> and that only ever happens *once* for any object. You only have 1 chance to do
> any necessary cleanup. Anything missed is considered a leak. So, the fact that
> allocated objects are only freed on the condition of an "expired" flag is a bit
> troubling. You probably see something I don't. (I think this function is a
> pattern copied from elsewhere in the file)
The GC follows the pattern used elsewhere, and this pattern is to only mark as
expired and free the data our self using the "outstanding" tables.
> 3. It looks like the PrivateTable stores a pointer to a string from the Lua
> stack (which will eventually point to garbage).
The strings are only used while dissecting a single package, and does not have
to live after that. If we can get a GC during a single dissection of a package
this will be a problem. I'll have a look at it.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.
