W3C home > Mailing lists > Public > www-lib@w3.org > July to September 2000

Re: AW: Solution for possible crash if using SSL

From: <jose.kahan@w3.org>
Date: Fri, 28 Jul 2000 10:42:19 +0200 (MET DST)
Message-Id: <200007280842.KAA00571@tuvalu.inrialpes.fr>
To: "Kallweit, Heiner" <Heiner.Kallweit@commerzbank.com>
CC: www-lib@w3.org
Hello Heiner,

Good work. I have just some final doubts before making the commit.

In HTHost_forceFlush() you return HT_ERROR if the in_flush flag is set.
The only place where this may make a problem is in HTTP.c:1192, where
the return code is used to select the next HTTP automata state.

I'm not sure if we should return HT_ERROR or HT_OK or something else
then if we catch the flag.

I looked again at your previous mail, where you give the following stack:

>requests via Libwww and SSL. Every 100th request I got a core dump.
>Eventually I found out that there is a recursive function call. To cut a
>story short: HTHost_forceFlush -> HTTPEvent_Flush ->
>-> HTSSLWriter_write -> HTSSLReader_read -> HTHost_forceFlush

Do you remember where was the first HTHost_forceFlush called? That is, could
you give the whole stack up to that call?

It may be that your solution is good, but that it could be better to set
the in_flush flag in the function that will make the HTHost_forceFlush call
(I'm thinking about the SSL glue code). It may also be that there's an
extra HTHost_forceFlush call that shouldn't be called or that the problem
is elsewhere? 

I'll try to see if I can find something here too. If we don't make much
progress, I guess I'll propose your patch as an experimental one and differ
its integration into the main code. Just because I'm not sure about the
side effects.

Received on Friday, 28 July 2000 04:42:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:33:53 UTC