> Message: 6
> Date: Fri, 17 Jul 2009 17:30:11 -0700
> From: [email protected]
> Subject: debugging a crash in Curl_pgrsTime/checkPendPipeline?
> To: libcurl development <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=us-ascii
>
> Folks,
> The OpenSolaris packaging project recently switched to using PyCurl as
> the framework for performing network operations. In general, the
> transition has gone well; however, I've recently run across a segfault
> that a few users are seeing.
>
> It's with libcurl-7.19.4 and PyCurl-7.19.0. A couple of patches have
> been applied to PyCurl so that a reset() of an easy handle works
> properly.
>
> I've yet to reproduce the crash myself, but it appears to occur while
> performing downloads with a large number of files.
>
This feels similar to a set of issues we ran into with curl 7.18.x
This went away with 7.19 and I haven't seen again in 7.19.3 (which is
what we currently run). Somehow I feel like we ran into a similar
issue again if we tried to go past 7.19.3
We never investigated enough to get to the bottom of it, but yes,
Curl_pgrsTime/checkPendPipeline sounds right. So does downloading a
ton of files. Our repro was to download millions of files in the same
process. And even then it was a one in 100 million shot :(
Here's a relevant stacktrace (probably from a 7.18 version, but I've
seen a similar one from a build after 7.19.3):
Program terminated with signal 11, Segmentation fault.
[New process 21235]
#0 0x00007f5eb050f2fb in Curl_pgrsTime (data=0xbab1e,
timer=<value optimized out>) at progress.c:172
172 data->progress.t_connect =
(gdb) bt
#0 0x00007f5eb050f2fb in Curl_pgrsTime (data=0xbab1e,
timer=<value optimized out>) at progress.c:172
#1 0x00007f5eb052e0d2 in checkPendPipeline (conn=0x60dfa30) at multi.c:1983
#2 0x00007f5eb052e838 in multi_runsingle (multi=0x59005f0, easy=0x6e05ed0)
at multi.c:1337
#3 0x00007f5eb052f1e6 in multi_socket (multi=0x59005f0,
checkall=<value optimized out>, s=1919, ev_bitmask=0,
running_handles=0x7fffb9698314) at multi.c:1782
#4 0x00007f5eb052f32f in curl_multi_socket_action (multi_handle=0xb3690e,
s=3943, ev_bitmask=0, running_handles=0x7fffb9698190) at multi.c:1872
We have a note in our issue tracker:
"This is fixed in curl 7.19 but it looks like there was a regression
in a later version of curl. There are a couple of email messages
around something suspiciously similar in the curl-lib mailing list
between March and May."
Sorry I don't have more help for you.
--Nick
