[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [Libevent-users] Problems with deferred HTTP handlers over SSL



Hi Amarin,

I've retried it by looping curl and it indeed seg. faults after about 10k
invocations (just a guestimate). I did remove the sleep(1); to make it crash
faster, it doesn't really matter.

BTW: why did you use the evhtp_set_gencb()?
Example:
https://github.com/okoeroo/lcmaps-rest/blob/master/src/lcmapsd_httprest.c


	Oscar


On 13/1/12 9:20 PM, Oscar Koeroo wrote:
> Hi Amarin,
> 
> Could you checkout the "0.4.5" tag of libevhtp and rebuild with that one? I
> don't think master is the right starting point.
> 
> I tried your code and my Chrome (version 18.x devel), Firefox 9.0.1 and
> Opera 11.60 worked fine.
> 
> I've statically build your code against libevent release-2.0.16-stable and
> libevhtp 0.4.5 and dynamically linked it with OpenSSL 0.9.8 on my Mac.
> 
> In friendly letters all my browsers say "hello".
> 
> 
> 	Oscar
> 
> 
> On 13/1/12 8:50 PM, Amarin Phaosawasdi wrote:
>> Hi All,
>>
>> We're working on fixing an issue with one of our servers, which serves
>> HTTPS requests on one end, and makes asynchronous RPCs on the other end.
>>
>> The server uses libevhtp to serve HTTPS requests. But since it is also
>> based on libevent and we suspect it might have something to do with
>> bufferevent_openssl, we thought it is appropriate to post it here.
>>
>> When a HTTPS request comes in, a the server invokes an async RPC to an
>> internal server. When the RPC finishes, we then use the RPC results to
>> provide an HTTPS response to the browser.
>>
>> However, almost all the time the browser gives an error.
>> - "SSL received a record with an incorrect Message Authentication Code.
>> (Error code: ssl_error_bad_mac_read)." (in Firefox)
>> - "Error 107 (net::ERR_SSL_PROTOCOL_ERROR): SSL protocol error." (in Chrome)
>> - "Error 324 (net::ERR_EMPTY_RESPONSE): The server closed the connection
>> without sending any data. (in Chrome)
>>
>> Rarely, when the browser doesn't give an error, it either succeeds or
>> blocks forever.
>>
>> Repeated fails normally end with a segmentation fault in the server.
>>
>> When a synchronous RPC is used instead (everything is finished on the
>> callback stack), the error is gone and every request is successful.
>>
>> Also if the server is configured to serve HTTP requests instead of HTTPS,
>> it also always succeeds regardless or the RPC calling mode.
>>
>> Does anybody have an idea what might be going on?
>>
>> The attached code can be used to reproduce this issue. When the server is
>> run, use a browser to connect to https://127.0.0.1:1025.
>>
>> Tested with:
>> gcc/g++ 4.4.5
>> Both openssl 0.9.8 and 1.0.0f
>> libevhtp development branch
>> libevent master branch
>> Debian 2.6.39-bpo.2-amd64 x86_64
>>
>> Thank you,
>> Amarin
>>
> 
> 


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature