request pool cleanup handler

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

Good day. I'm working on 
. 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, 
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;
listener->cleanup = clndata;

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 

  - Leo
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: useful debuggery.txt
URL: <>

More information about the nginx mailing list