Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

leak #3

Closed
dvv opened this issue Oct 29, 2012 · 1 comment
Closed

leak #3

dvv opened this issue Oct 29, 2012 · 1 comment

Comments

@dvv
Copy link
Member

dvv commented Oct 29, 2012

leakage described in creationix/moonslice-luv#1 resides in pure luv, since the following code (barebone pseudo-HTTP server) shows constant growth of memory usage:

local utils = require('utils')
local p = utils.prettyPrint
local print = utils.print
utils.stdout = io.stdout
local luv = require('luv')

local function createServer(host, port, onConnection)
  local server = luv.newTcp()
  server:bind(host, port)
  function server:onconnection()
    local client = luv.newTcp()
    server:accept(client)
    onConnection(client)
  end
  server:listen()
  return server
end

local server = createServer("127.0.0.1", 8080, function (client)
  local function onend()
    chunk = "HTTP/1.0 200 OK\r\nConnection: Close\r\nContent-Type: text/html\r\nContent-Length: 14\r\n\r\nHello World\n\r\n"
    client:write(chunk, function ()
    end)
    client:shutdown(function ()
      client:close()
    end)
  end
  function client:ondata(chunk)
    onend()
  end
  function client:onclose()
  end
  client:readStart()
end)

repeat
until luv.runOnce() == 0

please, consider fixing. tia

@dvv
Copy link
Member Author

dvv commented Nov 17, 2012

please, consider applying http://busybox.net/~dvv/luv-1.patch:

  • appended -DLUV_STACK_CHECK=1
  • call luv_read_stop() on handle shutdown
  • coped with famous libuv on_read() assertion on handle is closed
  • coped with peer ECONNRESET

@dvv dvv closed this as completed Nov 25, 2012
@mythay mythay mentioned this issue Oct 21, 2015
squeek502 added a commit to squeek502/luv that referenced this issue May 10, 2020
The magic -1 was not very user friendly and wasn't documented, and making it an optional argument makes the most sense to me. This is fully backwards compatible, and will also error on cases where the offset could be used as a callback, but the user probably didn't intend it to be the callback, like:

    uv.fs_read(fd, 32, function() end, function() end)

which will give the error

    bad argument luvit#3 to 'fs_read' (number expected, got function)
squeek502 added a commit to squeek502/luv that referenced this issue May 10, 2020
The magic -1 was not very user friendly and wasn't documented, and making it an optional argument makes the most sense to me. This is fully backwards compatible, and will also error on cases where the offset could be used as a callback, but the user probably didn't intend it to be the callback, like:

    uv.fs_read(fd, 32, function() end, function() end)

which will give the error

    bad argument luvit#3 to 'fs_read' (number expected, got function)
squeek502 added a commit to squeek502/luv that referenced this issue May 10, 2020
The magic -1 was not very user friendly and wasn't documented, and making it an optional argument makes the most sense to me. This is fully backwards compatible, and will also error on cases where the offset could be used as a callback, but the user probably didn't intend it to be the callback, like:

    uv.fs_read(fd, 32, function() end, function() end)

which will give the error

    bad argument luvit#3 to 'fs_read' (number expected, got function)
squeek502 pushed a commit that referenced this issue Oct 15, 2020
Fixup timer:get_due_in() tests
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant