httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From j...@msoft.com (Jon Teichrow)
Subject Re: r->connection->aborted no longer set?
Date Mon, 27 Jul 1998 17:28:07 GMT
>> I ran into this problem a while back (see below, if interested) and if
you
>> send a space via ap_rputs you may have a bogus client which will, under
>> Windows, cause a GPF when accessed.  As a workaround, I used an exception
>> handler to catch the resulting GPF and manually set the aborted flag.
This
>> still did not do the trick - another GPF occured outside my module
because
>> of the bogus client.
>
>Huh?  Are you saying Windows gives a GPF when a socket connection is
>broken!?!?
>

Under Win95 1.3b7 (I have since ported to Solaris), yes.  I will retry
using 1.3.1 today.  When the following utility function was called,
ap_vbprintf caused a GPF because client was garbage.

int COutputManager::printf(const char *fmt, ...) const
{
    int n=0;
    va_list vlist;

    va_start(vlist, fmt);
    n = ap_vbprintf(m_r->connection->client, fmt, vlist);
    va_end(vlist);

    return n;
}

This the basic outline of what was happening:

1. Module gets a request.
2. Module connects to Oracle over slow VPN (production system
   will have Oracle on same box).
3. On browser during DB activity, click stop.
4. Meanwhile, module execution continues.  After data is
   retrieved from DB it is output via the printf statement
   which causes the GPF.



Mime
View raw message