httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Max Kellermann <>
Subject SIGSEGV when mod_apreq2 is not loaded; void*env?
Date Fri, 07 Jan 2005 09:44:34 GMT

I often forget to load mod_apreq2 (2.04-dev), and that results in a
segmentation fault:

Program received signal SIGSEGV, Segmentation fault.
0xb7cda252 in apreq_request (env=0x81fa068, qs=0x0) at
63              req->env      = env;

It's hard for users to find the cause of this problem. A "real" error
message would be appropriate.

When mod_apreq2 is not loaded (and installed its env module), the
default module is CGI. CGI requires an apr_pool_t* instead of an
request_rec* as env pointer.

I found no simple and elegant way to detect this, because the CGI
module cannot know whether the application was designed to use this
module. It cannot check the type of "void*env". One solution might be
to let all modules which need mod_apreq to import a symbol which is
exported by mod_apreq, but that still does not guarantee that
mod_apreq has been correctly initialized.

In general, I find the "void*env" handling in apreq quite dangerous.
The application which uses libapreq calls has to choose which env
module it would like to have (hard coded), but in the end the
administrator chooses which env module is used, by enabling or
disabling mod_apreq (runtime). IMHO, this discrepancy is not a
GoodThing(TM). All applications (modules) which run in the same
process have to be written to use the same env module (the 90%
solution), otherwise apreq's behaviour is undefined (SIGSEGV).

My idea: apreq_request (and apreq_env_*; are these public?) gets an
additional parameter, the env module. If an application passes
apache2_module, it can be sure that the request_rec pointer it also
passes will be understood.  Additionally, it imported the
apache2_module symbol from mod_apreq2 and the linker (dlopen) already
checked that mod_apreq2 was loaded.

This way, you could also drop the "const char*qs" parameter from
apreq_request. It can be replaced by a "query_string_module" which
receives the query string as env pointer.

This is an API/ABI change, but you could also add a new function with
that new parameter, and let the old function use the old global
apreq_env variable (and choose query_string_module if qs!=NULL).

If we agree on my solution, I will write a patch.


View raw message