www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Segfaults in std.net.curl default onReceiveHeader

Hey,

I currently have an application that's been running for a couple 
months in production without an issue. Recently, we made a couple 
changes unrelated to our network layer, and are currently getting 
segfaults in std.net.curl's HTTP, with the mostly default 
settings. I don't believe the changes we made would relate to 
this, but is it possible this is a user error? We do not set 
onReceiveHeader in our application.

They may be several hundred concurrent connections open, but they 
are carefully isolated within their own thread's with 
CurlOption.nosignal set.

This is a backtrace I got from one of the core dumps, they all 
look similar:

(gdb) bt
#0  0x00000000005e1242 in std.net.curl.Curl.throwOnStopped() ()
#1  0x00000000005e1676 in std.net.curl.Curl.onReceiveHeader() ()
#2  0x00000000005e1927 in 
std.net.curl.Curl._receiveHeaderCallback() ()
#3  0x00007fede92b1d2d in Curl_client_chop_write 
(conn=conn entry=0x7fea64059210, type=type entry=2,
     ptr=0x5ea5940 " W\272+\355\177", len=17) at sendf.c:457
#4  0x00007fede92b1eb0 in Curl_client_write 
(conn=conn entry=0x7fea64059210, type=type entry=2, 
ptr=<optimized out>,
     len=<optimized out>) at sendf.c:514
#5  0x00007fede92b03c5 in Curl_http_readwrite_headers 
(data=data entry=0x5ea5d40, conn=conn entry=0x7fea64059210,
     nread=nread entry=0x7fe7f5780d18, 
stop_reading=stop_reading entry=0x7fe7f5780d17) at http.c:3744
#6  0x00007fede92c6418 in readwrite_data (done=0x7fe7f5780da3, 
didwhat=<synthetic pointer>, k=0x5ea5db8,
     conn=0x7fea64059210, data=0x5ea5d40) at transfer.c:482
#7  Curl_readwrite (conn=0x7fea64059210, 
done=done entry=0x7fe7f5780da3) at transfer.c:1066
#8  0x00007fede92d037a in multi_runsingle 
(multi=multi entry=0x7fea6400bb30, now=..., 
data=data entry=0x5ea5d40)
     at multi.c:1521
#9  0x00007fede92d0b69 in curl_multi_perform 
(multi_handle=multi_handle entry=0x7fea6400bb30,
     running_handles=running_handles entry=0x7fe7f5780e74) at 
multi.c:1802
#10 0x00007fede92c7ffc in easy_transfer (multi=0x7fea6400bb30) at 
easy.c:717
#11 easy_perform (events=false, data=0x5ea5d40) at easy.c:805
#12 curl_easy_perform (easy=0x5ea5d40) at easy.c:824
#13 0x00000000005e14a6 in std.net.curl.Curl.perform() ()
#14 0x00000000005df041 in std.net.curl.HTTP.perform() ()

Another one which looks slightly different:

#0  0x00000000005de6f3 in 
std.net.curl.HTTP.Impl.onReceiveHeader() ()
#1  0x00000000005e16ee in std.net.curl.Curl.onReceiveHeader() ()
#2  0x00000000005e1987 in 
std.net.curl.Curl._receiveHeaderCallback() ()
#3  0x00007f0ad8140d2d in Curl_client_chop_write 
(conn=conn entry=0x7f05e819e190, type=type entry=2,
     ptr=0x7f0a1a4e0200 "", len=23) at sendf.c:457
#4  0x00007f0ad8140eb0 in Curl_client_write 
(conn=conn entry=0x7f05e819e190, type=type entry=2, 
ptr=<optimized out>,
     len=<optimized out>) at sendf.c:514
#5  0x00007f0ad813f3c5 in Curl_http_readwrite_headers 
(data=data entry=0x3ec64b0, conn=conn entry=0x7f05e819e190,
     nread=nread entry=0x7f061bffddf8, 
stop_reading=stop_reading entry=0x7f061bffddf7) at http.c:3744
#6  0x00007f0ad8155418 in readwrite_data (done=0x7f061bffde83, 
didwhat=<synthetic pointer>, k=0x3ec6528,
     conn=0x7f05e819e190, data=0x3ec64b0) at transfer.c:482
#7  Curl_readwrite (conn=0x7f05e819e190, 
done=done entry=0x7f061bffde83) at transfer.c:1066
#8  0x00007f0ad815f37a in multi_runsingle 
(multi=multi entry=0x7f05e80bae70, now=..., 
data=data entry=0x3ec64b0)
     at multi.c:1521
#9  0x00007f0ad815fb69 in curl_multi_perform 
(multi_handle=multi_handle entry=0x7f05e80bae70,
     running_handles=running_handles entry=0x7f061bffdf54) at 
multi.c:1802
#10 0x00007f0ad8156ffc in easy_transfer (multi=0x7f05e80bae70) at 
easy.c:717
#11 easy_perform (events=false, data=0x3ec64b0) at easy.c:805
#12 curl_easy_perform (easy=0x3ec64b0) at easy.c:824
#13 0x00000000005e1506 in std.net.curl.Curl.perform() ()
#14 0x00000000005df0a1 in std.net.curl.HTTP.perform() ()
May 09 2015