Segfault in lua5.5

[myzhan]

OS: macos Tahoe 26.3.1
Lua: 5.5.0
luv: 1.52.1-0 from luarocks

Code to trigger segfault.

local uv = require "luv"

local timer1 = uv.new_timer()
timer1:start(100, 0, function()
    timer1:close()
end)
uv.run()

uv.loop_close()

local timer2 = uv.new_timer() -- segfault!

[squeek502]

To clarify, what behavior are you expecting from this?

Here's the uv.loop_close() documentation:

Closes all internal loop resources. In normal execution, the loop will automatically be closed when it is garbage collected by Lua, so it is not necessary to explicitly call loop_close(). Call this function only after the loop has finished executing and all open handles and requests have been closed

We could probably avoid the segfault by adding a NULL check here:

luv/src/luv.c

Line 802 in f65fe9d

ctx = (luv_ctx_t*)lua_touserdata(L, -1);

Unsure what the performance tradeoffs of that would be.

[myzhan]

A lua error is better. I'm testing a large codebase with lua 5.5. The change in the GC triggers this issue, I call loop_close instead of GC, to reproduce this issue explicitly.

[squeek502]

Ah, then this could be similar to #437 / #654 (review)

[truemedian]

Realistically speaking I don't think there is a correct way to use luv.loop_close() because you'd have to guarantee that all luv handles were closed before you can call loop_close.

I call loop_close instead of GC, to reproduce this issue explicitly.

If this is garbage collector related then you need to reproduce luv's loop garbage collector.

luv.walk(function (handle)
  if not handle:is_closing() then
    handle:close()
  end
end)

while not luv.loop_close() do
  luv.run()
end

The important thing to note is that luv's loop can only be garbage collected when the lua state is closing (because it's a userdata with a reference in the registry), so calling luv.loop_close() and then any other luv function puts the program in a state that is otherwise impossible without luv.loop_close().

[myzhan]

I'm not calling loop_close. In fact, I'm using luv with busted for unittest.

Busted clears package.loaded between test files, and under Lua 5.5's more aggressive GC, the luv loop userdata gets collected between tests. When a subsequent test calls uv.new_timer(), the process crashes with a segfault instead of raising a Lua error.

local uv = require "luv"

-- Step 1: Normal usage
local timer = uv.new_timer()
timer:start(100, 0, function() timer:close() end)
uv.run()

-- Step 2: Remove from cache and force GC
-- GC will reclaim luv's loop userdata, calling uv_loop_close via __gc
package.loaded["luv"] = nil
collectgarbage("collect")
collectgarbage("collect")

-- Step 3: Re-require and use → SEGFAULT
local uv2 = require "luv"
local timer2 = uv2.new_timer()  -- segfault here

[squeek502]

Haven't been able to reproduce it with GC (only tested on Windows so far; EDIT: also unable to reproduce it on Linux with GC alone), but that makes sense to me. The luv_ctx_t that stores the pointer to the loop outlives the loop, and luv's loop_gc implementation does not NULL out the loop in the ctx, so during the second luaopen_luv call, the loop is a stale non-NULL pointer and doesn't get re-initialized. The segfault happens when that stale pointer is used afterwards (in the new_timer call in this case).

Potentially just a missing ctx->loop = NULL; in loop_gc? Unless there's something I'm missing that would make that unsafe.

[squeek502]

If you have a reliable reproduction without loop_close() can you try with the branch from #821?