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() ()
