request pool cleanup handler

Leo P. junk at slact.net
Mon Oct 19 03:02:17 MSD 2009


Good day. I'm working on http://github.com/slact/nginx_http_push_module 
. and I've got this one nasty bug that I'm having a bit of trouble with.

An aside first, though. The way this thing works is by setting up an 
rbtree in a shared memory zone. Waiting listener requests are queued up 
in channels (represented by nodes on the shared rbtree). Naturally, when 
a listener request is finished or aborted, I want it dequeued from a 
channel's "waiting list". I am doing this with a request pool cleanup 
handler, using the following piece of code to set it up:

//test to see if the connection was closed or something.
r->read_event_handler = ngx_http_test_reading; //r is a long-polling 
listener request.
//attach a cleaner to remove the request from the channel, if need be 
(if the connection goes dead or something)
ngx_http_push_listener_cleanup_t *clndata;
ngx_pool_cleanup_t     *cln = ngx_pool_cleanup_add(r->pool, 
sizeof(*clndata));
if (cln == NULL) { //make sure we can.
   return NGX_ERROR;
}
cln->handler = (ngx_pool_cleanup_pt) ngx_http_push_listener_cleanup;
clndata = (ngx_http_push_listener_cleanup_t *) cln->data;
clndata->channel=channel;
clndata->listener=listener;
ngx_shmtx_lock(&shpool->mutex);
listener->cleanup = clndata;
ngx_shmtx_unlock(&shpool->mutex);

Trouble is, I'm getting (occasional) segfaults from accessing said 
ling-polling listener requests that have already been freed. Meaning, I 
suspect, the request pool cleanup handler was not called.

Also, I am unable to reproduce this when worker_processes = 1;

Some possibly relevant valgrind output is attached. Coredumps are 
getting me nowhere, as said request memory will have already been freed 
by the time a segfault occurs.

My questions, then:
Are there any circumstances under which a request pool cleanup handler 
will fail to fire? Or am I debugging this in a completely wrong direction?
Is there a better way to have nginx call a handler upon request 
termination?

Thanque,
  - Leo
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: useful debuggery.txt
URL: <http://nginx.org/pipermail/nginx/attachments/20091018/5f9160c7/attachment.txt>


More information about the nginx mailing list