I have not yet run the nginx with valgrind. However, changing the
original lua file to the following fixes the issue. It turns out the
output can be 100MB+. I will keep digging.

local prox = 3201
local nrAgent = 8
ngx.print("coblitzstat\n")
for p = prox, prox+nrAgent-1 do
local l = "/prox" .. p .. ngx.var['request_uri']
print("copass: fetching location " .. l)
local res = ngx.location.capture(l)

if (res.status ~= ngx.HTTP_OK and res.status ~= 504) then
return(res.status)
end
if(res.status == ngx.HTTP_OK and string.len(res.body)> 0) then
ngx.print(res.body)
end
end



On 05/10/2011 05:54 AM, agentzh wrote:
> On Tue, May 10, 2011 at 11:45 AM, Sirsiwal, Umesh<usirsiwal@verivue.com> wrote:
>> Thanks agentzh,
>>
>> Here is some additional information:
>> This does not happen on every request. It happens 2-3 hours running 2000-16000 requests/sec (Lua and Nginx rock:))
>>
>> We are using CentOS 5.6 with 2.6.32-16 based Kernel.
>>
>> nginx -V
>> We have two custom modules which act as content handler:
>>
> Hmm, LuaJIT 2.0 beta7 passes ngx_lua's test suite completely with
> nginx 0.8.54 and 1.0.1 on my Slackware Linux, with or without valgrind
> and/or etcproxy. We cannot reproduce it on our side. Sigh. We cannot
> easily run your config due to your custom C modules which are not
> opensourced and are also open to lurking bugs.
>
> Your backtrace looks so funny that the lua_newthread function returned
> a pointer with the value -1, which is unspecified in the Lua
> documentation and is unlikely to happen. So it's very likely a
> consequence (rather than the real cause) of a corrupted heap that
> might appear much earlier than the crash.
>
> Could you try running your server with the standard Lua 5.1
> interpreter instead? If it does not crash any more, then it's very
> likely a bug in LuaJIT2.0 (or the way ngx_lua interacts with it in
> particular).
>
> Also, please consider running your server with valgrind's memcheck
> tool to see if there's any memory invalid reads/writes prior to the
> crash. Fortunately, valgrind runs very well on Linux, as compared to
> Mac OS X.
>
> Another suggestion is to further minimize your config to exclude your
> own modules such that we can run your sample on our side directly ;)
>
> Regards,
> -agentzh
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel@nginx.org
> http://nginx.org/mailman/listinfo/nginx-devel


_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://nginx.org/mailman/listinfo/nginx-devel