segfault after HTTP_MOVED_* and set_handlers()

[Stefano]

Hello,

This is a  question about the correct use of set_handlers request
method.

I have some handlers stacked by the first one content handler;
one of them processing the request needs to redirect and then close
the HTTP response with a HTTP_MOVED_PERMANENTLY;

so I thought that the following stacked handlers have to be removed
from the stack with a $r-set_handlers('PerlHandler' = undef) in a way
such:

$r-content_type('text/html') ;
$r-header_out('Location', '/go/there') ;
$r-set_handlers('PerlHandler' = undef) ;
return HTTP_MOVED_PERMANENTLY ;

What I see is a couple of side effects:

 - Apache exit correctly, but the following request it serves arises a
   segfault at an unpredictable execution point
 - Apache faults immediately, child dies
 
I've traced childs with strace and Apache::DB and using the latter one
childs segfault also trying to print a value from the debugging shell:
  
  DB  p $var


So I removed all the undefining calls and everithing returns to work.

Does that mess up the apache child pool used by mod_perl ?

What I'm asking is 
 a) when is a good idea use set_handlers(PerlHandler = undef)
 b) is the segfault I've obtained a bug in mod_perl ?


Thanks,
Stefano di Sandro

Re: segfault after HTTP_MOVED_* and set_handlers()

[Geoffrey Young]

Stefano wrote:

Hello,

This is a  question about the correct use of set_handlers request
method.

I have some handlers stacked by the first one content handler;
one of them processing the request needs to redirect and then close
the HTTP response with a HTTP_MOVED_PERMANENTLY;

so I thought that the following stacked handlers have to be removed
from the stack with a $r-set_handlers('PerlHandler' = undef) in a way
such:

	$r-content_type('text/html') ;
	$r-header_out('Location', '/go/there') ;
	$r-set_handlers('PerlHandler' = undef) ;


you can't currently set_handlers() for the current phase.  sorry.  there was a patch 
floating around to do this, but it was never integrated.

	return HTTP_MOVED_PERMANENTLY ;


that should terminate the phase entirely and keep the other handlers from running - no 
need to explicitly undef the stack anyway.

HTH

--Geoff

segfault after HTTP_MOVED_* and set_handlers()

[Stefano]

Hello,

This is a  question about the correct use of set_handlers request
method.

I have some handlers stacked by the first one content handler;
one of them processing the request needs to redirect and then close
the HTTP response with a HTTP_MOVED_PERMANENTLY;

so I thought that the following stacked handlers have to be removed
from the stack with a $r-set_handlers('PerlHandler' = undef) in a way
such:

$r-content_type('text/html') ;
$r-header_out('Location', '/go/there') ;
$r-set_handlers('PerlHandler' = undef) ;
return HTTP_MOVED_PERMANENTLY ;

What I see is a couple of side effects:

 - Apache exit correctly, but the following request it serves arises a
   segfault at an unpredictable execution point
 - Apache faults immediately, child dies
 
I've traced childs with strace and Apache::DB and using the latter one
childs segfault also trying to print a value from the debugging shell:
  
  DB  p $var


So I removed all the undefining calls and everithing returns to work.

Does that mess up the apache child pool used by mod_perl ?

What I'm asking is 
 a) when is a good idea use set_handlers(PerlHandler = undef)
 b) is the segfault I've obtained a bug in mod_perl ?


Thanks,
Stefano di Sandro

segfault after HTTP_MOVED_* and set_handlers()

[Stefano]

Hello,

This is a  question about the correct use of set_handlers request
method.

I have some handlers stacked by the first one content handler;
one of them processing the request needs to redirect and then close
the HTTP response with a HTTP_MOVED_PERMANENTLY;

so I thought that the following stacked handlers have to be removed
from the stack with a $r-set_handlers('PerlHandler' = undef) in a way
such:

$r-content_type('text/html') ;
$r-header_out('Location', '/go/there') ;
$r-set_handlers('PerlHandler' = undef) ;
return HTTP_MOVED_PERMANENTLY ;

What I see is a couple of side effects:

 - Apache exit correctly, but the following request it serves arises a
   segfault at an unpredictable execution point
 - Apache faults immediately, child dies
 
I've traced childs with strace and Apache::DB and using the latter one
childs segfault also trying to print a value from the debugging shell:
  
  DB  p $var


So I removed all the undefining calls and everithing returns to work.

Does that mess up the apache child pool used by mod_perl ?

What I'm asking is 
 a) when is a good idea use set_handlers(PerlHandler = undef)
 b) is the segfault I've obtained a bug in mod_perl ?


Thanks,
Stefano di Sandro