RE: Lua GC breaks with socket.select on Solaris 5.10: Solved

[Andrzej Pruszynski <andrzej.pruszynski@...>]

Hello,

Problem described below in my email from 2011/08/04 to your forum is now fixed. At origin is the default compilation of lua executable as stand-alone. Socket module uses lua library and when calling socket from lua, Garbage Collector seems to be fooled (two Garbage Collectors, possibly same memory being freed twice).

So solution is to create lua executable depending on the lua library.

By the way it may be a problem of most Linux distributions of LUA, where LUA module is provided as standalone and socket module uses lua library.

Thx,

Andrzej


------------------------------------------------------------------------------
  
Hello,

Lua is used on many ?'5.10 Generic_142909-17 sun4v sparc SUNW,SPARC-Enterprise-T5120' servers and in all cases copas.lua module is used, lua 5.1.4 will trigger core dump, after some time. I used official luasocket-2.0.2 and unofficial luasocket-2.0.3.

I managed to focus on garbage collector and socket.select used by copas.lua and the following script demonstrates the problem (it works fine on Windows XP 32, Windows 7.0 64):

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
require("socket")
local i = 0

while true do
  t = {}
  socket.select(nil, nil, 0.05)
  i = i + 1
  if ( i % 10 == 0 ) then collectgarbage("collect") end
  print("kB", gcinfo(), i)
t = nil end
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Available memory goes down from 40 kB to 0 when 'i' reaches 400 and then memory counter shows '4194303' when loop reaches 410:


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
kB????? 2?????? 409
kB????? 4194303 410
kB????? 0?????? 411
kB????? 0?????? 412
kB????? 0?????? 413
kB????? 0?????? 414
kB????? 0?? ????415
kB????? 0?????? 416
kB????? 0?????? 417
kB????? 1?????? 418
kB????? 1?????? 419
kB????? 4194302 420
kB????? 4194303 421
kB????? 4194303 422
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

When I use 'msleep' module setting the same timeout, 'collect' keeps the memory size around 38 kB.


If 'collectgarbage("collect")' is not used, something different happens. Memory goes up and down in two waves reaching near 0 in ~ 1100 loop steps and then it will go up forever (well, till system has free memory available).

------------------------------------------------------------------------------