• Steven Wright (84/84) May 09 2015 Hey,

"Steven Wright" <sprw121 gmail.com> writes:

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



std.net.curl.Curl._receiveHeaderCallback() ()

(conn=conn entry=0x7fea64059210, type=type entry=2,
     ptr=0x5ea5940 " W\272+\355\177", len=17) at sendf.c:457

(conn=conn entry=0x7fea64059210, type=type entry=2, 
ptr=<optimized out>,
     len=<optimized out>) at sendf.c:514

(data=data entry=0x5ea5d40, conn=conn entry=0x7fea64059210,
     nread=nread entry=0x7fe7f5780d18, 
stop_reading=stop_reading entry=0x7fe7f5780d17) at http.c:3744

didwhat=<synthetic pointer>, k=0x5ea5db8,
     conn=0x7fea64059210, data=0x5ea5d40) at transfer.c:482

done=done entry=0x7fe7f5780da3) at transfer.c:1066

(multi=multi entry=0x7fea6400bb30, now=..., 
data=data entry=0x5ea5d40)
     at multi.c:1521

(multi_handle=multi_handle entry=0x7fea6400bb30,
     running_handles=running_handles entry=0x7fe7f5780e74) at 
multi.c:1802

easy.c:717





Another one which looks slightly different:


std.net.curl.HTTP.Impl.onReceiveHeader() ()


std.net.curl.Curl._receiveHeaderCallback() ()

(conn=conn entry=0x7f05e819e190, type=type entry=2,
     ptr=0x7f0a1a4e0200 "", len=23) at sendf.c:457

(conn=conn entry=0x7f05e819e190, type=type entry=2, 
ptr=<optimized out>,
     len=<optimized out>) at sendf.c:514

(data=data entry=0x3ec64b0, conn=conn entry=0x7f05e819e190,
     nread=nread entry=0x7f061bffddf8, 
stop_reading=stop_reading entry=0x7f061bffddf7) at http.c:3744

didwhat=<synthetic pointer>, k=0x3ec6528,
     conn=0x7f05e819e190, data=0x3ec64b0) at transfer.c:482

done=done entry=0x7f061bffde83) at transfer.c:1066

(multi=multi entry=0x7f05e80bae70, now=..., 
data=data entry=0x3ec64b0)
     at multi.c:1521

(multi_handle=multi_handle entry=0x7f05e80bae70,
     running_handles=running_handles entry=0x7f061bffdf54) at 
multi.c:1802

easy.c:717