[sldev] SNOW-2 (Curl crash) update

[Philippe Bossut (Merov Linden)]

Hi,

Time for an update on this. Short story: we have new curl libs for  
Windows using c-ares for DNS lookup and openssl. I've been testing  
quite a bit and couldn't get it to crash. Nice!

This is no guarantee it fixes SNOW-2 for good as there's no 100% repro  
cases but it's good enough to envision distributing Snowglone builds  
that use those libs and see if it reduces significantly curl crashers  
rate.

More on the best plan to bring that to Snowglobe later. In the  
meantime, I'm sure you guys wanted to know where this bug was heading  
to.

Cheers,
- Merov



On Jul 3, 2009, at 8:42 PM, Philippe Bossut (Merov Linden) wrote:

> Hi,
>
> Wow! Thanks for all the feedback (public and private) on that one!
> Looks like we're locking that nasty bug in our crosshair which is
> great considering it's responsible for 10% of all crashers. Thanks a
> lot to Thickbrick who identified the libcurl known issue.
>
> I'm going to try to summarize the proposed actions and give my view on
> each:
> - Use LLCurlEasyRequest only (drop LLCurlRequest): that could be OK
> for the map but, considering we want to use http for all textures
> eventually, we can't really go with a system that open and close
> connections like crazy. Could be a disaster perf wise. We should
> consider this bug as an opportunity to fix LLCurlRequest for good and
> help the viewer in general, beyond the map. I'm sure Steve and Bao
> will thank us later (not to mention the residents... :) )
> - Work around the bug in LLCurlRequest: considering that we do support
> threads, we could actually run all curl code in its own thread using
> the easy interface (synchronous) only. I'm not a big fan of that
> solution either as we do have quite a bit of requests going on at the
> same time. My instrumentation of the code shows that we typically run
> 6 simultaneous requests at the beginning of a session (using
> LLCurlEasyRequest though) and up to 12 simultaneous request while
> browsing the map. We don't really want to queue 12 requests I think.
> If we use http fetch for all textures of a scene, I'm quite sure it's
> going to be much more simultaneous requests.
> - Update libculr to a more recent version and see if that fixes the
> problem: as pointed to by Thickbrick, the trace pattern we have seems
> to be a known existing bug so that's likely not enough for a solution.
> - Use the c-ares resolver for libcurl (proposed by Tofu): that seems
> to be the more promising and general solution, making no compromise
> and keeping the wrapping llcurl.cpp code simple, multiplatform and
> general.
>
> Unless someone comes up with a horror story of why we shouldn't do
> that, I'll be working with Tofu next week to get that into Snowglobe.
>
> Thanks again to all proposing solutions and commenting on this thread.
> That feels good to see the community work :)
>
> Cheers,
> - Merov
>
>
> On Jul 3, 2009, at 9:49 AM, Tofu Linden wrote:
>
>> Thickbrick Sleaford wrote:
>>> There is also an unfixed windows-only crash in libcurl:
>>>
>>> http://curl.haxx.se/docs/knownbugs.html
>>>> 64. The threaded resolver used in libcurl on Windows has some kind
>>>> of race
>>>> problem when multiple simultanoes resolves are done, like with the
>>>> multi
>>>> interface transferring many files in parallell:
>>>> http://curl.haxx.se/mail/lib-2009-04/0028.html
>>
>> That's not good.
>> The good news is... the c-ares resolver option for libcurl works on
>> Windows (last I tried) so we could switch to that and dodge the cited
>> bug.  There just hasn't been a point until now.
>>
>> _______________________________________________
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/SLDev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting  
> privileges