__gc metamethod not running for mysql statement handles causes memory leak

[GoogleCodeExporter]

What steps will reproduce the problem?

do the following in a loop:

1. local sth = dbh:prepare(sql)
2. sth:execute(...)
3. sth:fetch()
4. collectgarbage()

What is the expected output? What do you see instead?

the statement handles aren't being garbage collected and process vm size
grows, unless sth:close() is called explicitly

What version of the product are you using? On what operating system?

0.4 on Lua 5.1.4 (Linux)

Please provide any additional information below.

I'm digging around looking for what's holding references to the statement
handle udata, if I find it I'll submit a patch for review

Original issue reported on code.google.com by richardh...@gmail.com on 21 Apr 2010 at 5:33

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

sorry for the bad intel, the __gc metamethod is running, the leak is caused by
something else, here's a test case:

local sth = dbh:prepare[[ SELECT 1 + ? ]]
local i = 0
while true do
   i = i + 1
   sth:execute(i)
   local row = sth:fetch()
end

calling :execute(...) multiple times on a statement handle is leaky somehow

Original comment by richardh...@gmail.com on 21 Apr 2010 at 5:49

[GoogleCodeExporter]

solved this now, just need a:

+    if (statement->metadata) {
+        mysql_free_result(statement->metadata);
+    }

luadbi-read-only/dbd/mysql/statement.c near the top of:
static int statement_execute(lua_State *L)

I'd send a patch with this and a couple of other fixes in it to the mysql 
driver if
you let me know where to send it

Original comment by richardh...@gmail.com on 21 Apr 2010 at 6:18

[GoogleCodeExporter]

Thanks for the patch! I'll apply it to trunk ASAP.

Original comment by nr...@ii.net on 12 May 2010 at 1:53

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by nr...@ii.net on 16 Jul 2010 at 6:28

• Changed state: Fixed