httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Smith <>
Subject Re: Proposed Lua backport for 2.4
Date Mon, 25 Mar 2013 18:38:24 GMT
On 3/13/2013 1:12 PM, Daniel Gruno wrote:
> On 03/13/2013 08:39 PM, Gregg Smith wrote:
>> On 3/13/2013 4:44 AM, Daniel Gruno wrote:
>>> On 03/13/2013 02:50 AM, Gregg Smith wrote:
>>>> Hi Daniel,
>>>> I'm seeing segfaults on that dreadful Windows OS when using
>>>> LuaMapHandler&   LuaRoot together.
>>> The backtrace was actually quite helpful :) It would appear that the bug
>>> (perhaps) pre-dates my work on mod_lua (or it could be something I've
>>> missed completely, who knows).
>>> I can see that vm_construct is creating, or attempting to create, a lua
>>> VM which returns a null pointer meaning that part failed, but it doesn't
>>> check whether the VM is null, making munge_path segfault. At the same
>>> time, the lifecycle_pool being passed is also NULL, which makes even
>>> less sense to me, since you can see in the backtrace that it wasn't null
>>> when it got passed to ap_lua_get_lua_state.
>>> Can you tell me which exact lua directives you used for this? which
>>> LuaScope, LuaCodeCache and so on?
>> <IfModule lua_module>
>>    AddHandler lua-script .lua
>>    LuaMapHandler /testlua /usr/etc/lua/example.lua
>>    LuaRoot /usr/etc/lua
>> <Directory /usr/etc/lua>
>>      Options All
>>      AllowOverride None
>>      Require all granted
>> </Directory>
>> </IfModule>
>> So since not specifically configured, the defaults of once and stat
>> respectively.
>> Regards,
>> Gregg
> I am unable to get my own server to segfault, and I can't seem to find
> anything in the code that would cause the pool to suddenly become null.
> Your backtrace seems to indicate that your request calls:
> ap_lua_get_lua_state(apr_pool_t * lifecycle_pool=0x0258c0e8,
> ap_lua_vm_spec * spec=0x0258b658, request_rec * r=0x0258a120)
> which then calls:
> vm_construct(lua_State * * vm=0x036efdc0, void * params=0x0258b658,
> apr_pool_t * lifecycle_pool=0x00000000)
> except lifecycle_pool never gets changed anywhere in the code, it's just
> passed straight through to whatever made it turn into
> 0x000000000 is beyond my eyes to spot.
> If anyone else can spot something I'm missing, please do speak up,
> otherwise I'll probably chalk this one down to a Windows oddity.

It was suggested to me a few days ago off list to give the old module a 
try pre r1200614. I did just that yesterday and it works and no 
segfaults. Just FYI.



View raw message