<div dir="ltr"><div>I think i would go with Piotr's suggestion, I had only started to dig into the code, so hadn't got as far as he did (I took the weekend off)!<br><br></div>thanks again<br></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Mon, Oct 21, 2013 at 7:49 PM, Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello!<br>
<div class="im"><br>
On Mon, Oct 21, 2013 at 05:50:31PM +0000, Agent Coulson wrote:<br>
<br>
> Hi!<br>
><br>
> thanks for that input, I have done some debugging and examined the SSL<br>
> context when this state arrises.  Two SSL* structs (from different<br>
> connections) point to the same packet data.  Disabling the read_ahead flag<br>
> mitigates this.<br>
><br>
> I've attached a patch, after applying I was unable to repro using<br>
> openssl-1.0.1e.<br>
><br>
> I'll submit a report to the upstream openssl project.<br>
<br>
</div>Disabling the read_ahead as a workaround looks wrong for me.<br>
While it probably reduces a chance for a problem to appear, it's<br>
likely still there.<br>
<br>
Have you tried looking into the OpenSSL code to find out what<br>
causes the actual problem?<br>
<br>
I think it's likely SSL_MODE_RELEASE_BUFFERS related (and I indeed<br>
can't reproduce the error without SSL_MODE_RELEASE_BUFFERS set),<br>
but I don't see any obvious problems in the code.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Maxim Dounin<br>
<a href="http://nginx.org/en/donation.html" target="_blank">http://nginx.org/en/donation.html</a><br>
<br>
_______________________________________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
</div></div></blockquote></div><br></div>