I can't tell if this fault happens on other architectures. Also this is a
quite unstable behaviour, deep within my platform, where calls are scheduled
as part of a web service. So it isn't trivial to debug or extract sample
code.

Basically this happens on scheduling a keep-alive (easy_resetted) handle from
within a multi callback. I do this in a IO callback function that is called
when a READ/WRITE poll has selected the file descriptor:

while ( CURLM_CALL_MULTI_PERFORM ==
                (code = curl_multi_socket_action(inf->curl,
                                         fd, 0, &inf->handles)) );
...
then later on

if ( NULL != (msg=curl_multi_info_read(curl,&quelen)) ) {
        switch ( msg->msg ) {
                case CURLMSG_DONE:
                        code = handle_list_req_ready(inf, msg); break;
...

where handle_list_req_ready finishes a request and schedules another one on
int handle_list_req_ready( struct module_info* inf, CURLMsg* msg )
{
        CURL* conn = msg->easy_handle;
...
        curl_easy_getinfo(conn, CURLINFO_RESPONSE_CODE, &code );
...
        if ( code == 200 ) {
                curl_multi_remove_handle(inf->curl, conn );
                conn = setup_week_request( req, conn );
                curl_multi_add_handle(inf->curl, conn );
        }

here setup_week_request does the request setup by resetting the conn
easy_handle and feeding it with the new paramteres (different URL).

The program that executes this code is called as an fcgi script from an apache
httpd.

Sometimes it happens that the following
        while ( CURLM_CALL_MULTI_PERFORM ==
                                (curl_multi_socket_all(inf->curl,
                                                       &inf->handles)) );
loop throws a SIG11 within getenv called through curl_getenv.

Once this happened it will happen again until I reset the httpd by reload
which results in reloading the fcgi program.

So I conclude from this a bit strange behaviour that the problem arises from a
possible architecture specific optimization or some quirk in the apache
char**environ, that it provides for the fcgi process.

I modified the curl_getenv to return NULL in any case, which is completely
satisfying for my usage. That solves my issue. I also debugged the values
and noticed that the requested environment variables return NULL anyway,
since they are all uset (PROXY).

I will execute the code with a memory checker to be sure and then I will try
to modify the curl_getenv to access the environ directly to see if the
SEGFAULT remains.
Received on 2008-03-13