Hi Neil

I managed to kludge it into working by removing the bits from config. i.e
replacing:

    rv = apr_sockaddr_info_get(&sockaddr,
                               CONFIG_VALUE(m->addr, "localhost"),
                               APR_UNSPEC,
                               CONFIG_VALUE(m->port, 4000),
                               0,
                               r->pool);

with:

    rv = apr_sockaddr_info_get(&sockaddr,
                               "localhost",
                               APR_UNSPEC,
                               9090,
                               0,
                               r->pool);

However this brings up an unrelated problem in the following code:

    add_header(t, "SCRIPT_NAME", r->uri);
    if (r->path_info) {
        int path_info_start = find_path_info(r->uri, r->path_info);
        add_header(t, "SCRIPT_NAME", apr_pstrndup(r->pool, r->uri,
                                                  path_info_start));
        add_header(t, "PATH_INFO", r->path_info);
    }
    else {
        /* skip PATH_INFO, don't know it */
        add_header(t, "SCRIPT_NAME", r->uri);
    }

This results in the SCRIPT_NAME header being duplicated.

Thanks,
Tom


On Monday 16 January 2006 15:23, Thomas Yandell wrote:
> Hi Neil,
>
> Please see below.
>
> On Friday 13 January 2006 21:13, you wrote:
> > On Wed, Jan 11, 2006 at 10:39:22AM +0000, Thomas Yandell wrote:
> > > [Wed Jan 11 10:33:44 2006] [notice] child pid 4656 exit signal
> > > Segmentation fault (11)
> >
> > Ouch.
>
> Yep.
>
> > Unfortunately that doesn't provide much of a clue as to
> > what's wrong.  An easy thing to try is to set LogLevel to "debug".
> > You should get a better idea of what mod_scgi is doing when it dies.
>
> I got this:
>
> [Mon Jan 16 14:56:53 2006] [debug] mod_scgi.c(498): [client 127.0.0.5]
> connecting to server
>
> I tried to add extra debug warnings to narrow it down. In particular in the
> open_socket function i replaced the following:
>
>     rv = apr_sockaddr_info_get(&sockaddr,
>                                CONFIG_VALUE(m->addr, "localhost"),
>                                APR_UNSPEC,
>                                CONFIG_VALUE(m->port, 4000),
>                                0,
>                                r->pool);
>     if (rv) {
>         log_err(APLOG_MARK, r, rv, "apr_sockaddr_info_get() error");
>         return rv;
>     }
>
> with
>
>     log_debug(APLOG_MARK, r, "open_socket: 5");
>
>     rv = apr_sockaddr_info_get(&sockaddr,
>                                CONFIG_VALUE(m->addr, "localhost"),
>                                APR_UNSPEC,
>                                CONFIG_VALUE(m->port, 4000),
>                                0,
>                                r->pool);
>     if (rv) {
>         log_err(APLOG_MARK, r, rv, "apr_sockaddr_info_get() error");
>         return rv;
>     }
>
>     log_debug(APLOG_MARK, r, "open_socket: 6");
>
> and in the error log I get:
>
> ...
> [Mon Jan 16 15:10:15 2006] [debug] mod_scgi.c(434): [client 127.0.0.5]
> open_socket: 3
> [Mon Jan 16 15:10:15 2006] [debug] mod_scgi.c(438): [client 127.0.0.5]
> open_socket: 4
> [Mon Jan 16 15:10:15 2006] [debug] mod_scgi.c(442): [client 127.0.0.5]
> open_socket: 5
>
> and then nothing.
>
> > You may also want to add move debug messages to the source to narrow
> > it down.  Another idea is to attach to the Apache process using gdb.
> > That's a little tricky though.
> >
> > > I am using the libapache2-mod-scgi from debian unstable, but have also
> > > compiled the module myself with the same results.
> >
> > What's the version of Apache?  Are you just doing a simple GET
> > request or something more complicated?
>
> Current apache2 from unstable. Happens with prefork and worker mpm's. Is a
> simple GET request.
>
> > > I hope you don't mind me asking you, I could not find an appropriate
> > > mailing list.
> >
> > Contacting me is fine.  You can also try the
> > quixote-users@mems-exchange.org list as mod_scgi users tend to hang
> > out there too.
> >
> >   Neil
>
> Cc'd to list.
>
> Thanks,
> Tom

--
Thomas Yandell
Technical Consultant
Viper Code Limited
t: +44 (0)7855 399853
e: tom@vipercode.com
w: www.vipercode.com