[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: crash in Lua 5.1 and 5.2: calling C function from unloaded lib
- From: Josh Haberman <jhaberman@<a href="/cgi-bin/echo.cgi?gmail.com">...</a>>
- Date: Mon, 9 Apr 2012 07:32:17 -0700
On Mon, Apr 9, 2012 at 1:07 AM, Robert G. Jakabosky
> On Sunday 08, Josh Haberman wrote:
> To support safe unloading the Lua C API would need to be changed provide a way
> to tell the VM what module a C function is a part of.
If Lua can't unload modules safely, why is it unloading them at all?
There is no warning in the documentation of __gc that improper use can
SEGV the interpreter. It seems counter to Lua's goal of being an
embeddable language that a Lua program can take down the whole
process. Especially since it is not obvious how to trigger this
>> Perhaps this is a GC-related bug where
>> the loaded library is collected prematurely?
> No, the collection order is correct.
I'm not sure how you can call the collection order "correct" when I
was able to reference a collected object.
> local ext = require "ext"
> atexit(function() ext.nop() end)
How should a person who sees this SEGV in a large program know how to
fix it? I ran into this problem when using lunitx
(https://github.com/dcurrie/lunit), and I had no idea why I was
getting SEGVs inside of Lua. The atexit() function was implemented
and called from inside lunitx; I had no idea that a __gc metamethod
was involved at all.