Re: [NSE] rpc.lua Portmapper list cached in the NSE registry

[Patrick Donnelly <batrick () batbytes com>]

Hi Patrik,

On Sat, May 15, 2010 at 1:49 AM, Patrik Karlsson <patrik () cqure net> wrote:
> Hi Djalal,
>
> Reading the last line of the PIL documentation makes me wonder if this will actually work as intended [1].
> I had some similar problems with my AFP implementation [2].
> As far as I can tell the data won't be collected as long as the key is  a number, boolean or string.
>
> Patrick, could you please shed some light on this?

Lua uses a mark and sweep collector. Periodically it goes around
marking all objects that can be accessed by a Lua program. For weak
tables, it only marks both the <key, value> pairs as accessible if the
*weak* key/value (could be both for a weak key and weak value table)
is accessible. (The strongly referenced object is marked if it is
accessible elsewhere or if the the paired weak object is accessible
elsewhere.) The consequence of this is that if *either* the key or
value is collected, then the entire pair is collected. Lua does make
one caveat on weak keys, if they are strings/booleans/numbers then
they are *not considered collectible objects* (strings actually are,
but from a weak table perspective they are not).

Here is an example:

batrick@neverwinter:~$ lua
Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
> t = setmetatable({a = {}, [1] = {}, [{}] = {}}, {__mode = "k"})
> for k,v in pairs(t) do print(k,v) end
a       table: 0x1018d90
table: 0x10191e0        table: 0x1019230
1       table: 0x1019190
> collectgarbage "collect"
> for k,v in pairs(t) do print(k,v) end
a       table: 0x1018d90
1       table: 0x1019190

So, the number and string keys are considered strong references in a
weak keyed table even when the string "a" is collectible.


So for Djalal's patch:

+                       program_table[program] = program_table[program] or {}

If that variable "program" is a string then the weak keyed table will
not work as desired.

-- 
- Patrick Donnelly
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/