segfault when Hyper/Rustls client used with Git #6619
Comments
|
Unfortunately we still have a fair amount of tests cases that fail with the Hyper backend, and perhaps one of those is this problem. Can you make this appear without using git, perhaps with using the curl tool against the same URL or something? Can you make a build with debug symbols and perhaps use lldb (which always seems to be easier to get going on macOS) to investigate more specific details around the crash and local variables in that stack frame? |
I can't reproduce with only curl, at least, I tried sending exactly the same headers as were sent in the debug log and I can't get a segfault. I compiled with |
|
Okay, I figured out how to start a lldb session that's live at the time of the segfault, but not sure what to do next. Last bit of code in Hyper, arrow points to the line that's executing at the time of the segfault. strbuf_grow |
|
Well It seems rdi is 0 so after some research I noticed that for fwritebuf userdata should be set to strbuf with |
|
It will be helpful if you build with debug symbols present and perhaps run it with a debugger and check the local situation in the curl code at the position of the crash. Or perhaps run the curl test suite instead and help us fix the remaining test failures with Hyper as before they run fine, we can assume the problems are our own. There are still over a hundred failing test cases with Hyper. I'm not sure this issue is worth keeping open right now. |
Previously if a caller set CURLOPT_WRITEFUNCTION but did not set a CURLOPT_HEADERDATA buffer, Hyper would still attempt to write headers to the data->set.writeheader header buffer, even though it is null. This led to NPE segfaults attempting to use libcurl+Hyper with Git, for example. Instead, process the client write for the status line using the same logic we use to process the client write for the later HTTP headers, which contains the appropriate guard logic. As a side benefit, data->set.writeheader is now only read in one file instead of two. Fixes curl#6619. Fixes rustls/rustls-ffi#49. Fixes hyperium/hyper#2438.
Previously if a caller set CURLOPT_WRITEFUNCTION but did not set a CURLOPT_HEADERDATA buffer, Hyper would still attempt to write headers to the data->set.writeheader header buffer, even though it is null. This led to NPE segfaults attempting to use libcurl+Hyper with Git, for example. Instead, process the client write for the status line using the same logic we use to process the client write for the later HTTP headers, which contains the appropriate guard logic. As a side benefit, data->set.writeheader is now only read in one file instead of two. Fixes curl#6619. Fixes rustls/rustls-ffi#49. Fixes hyperium/hyper#2438.
Previously if a caller set CURLOPT_WRITEFUNCTION but did not set a CURLOPT_HEADERDATA buffer, Hyper would still attempt to write headers to the data->set.writeheader header buffer, even though it is null. This led to NPE segfaults attempting to use libcurl+Hyper with Git, for example. Instead, process the client write for the status line using the same logic we use to process the client write for the later HTTP headers, which contains the appropriate guard logic. As a side benefit, data->set.writeheader is now only read in one file instead of two. Fixes #6619 Fixes rustls/rustls-ffi#49 Fixes hyperium/hyper#2438 Closes #6971
I'm compiling the Hyper C bindings into libcurl, and then building git with this libcurl attached. Unfortunately I'm getting a segfault when I try to use the resulting git binaries.
Steps to reproduce:
install Git with Hyper+Rustls support (I set this up for Macs at
brew install meterup/safe/gitif you want to give it a try).Try to run
git fetch https://go.googlesource.com/goRunning with GIT_TRACE=1 GIT_CURL_VERBOSE=1 I get the following error message:
I tried running with RUST_BACKTRACE=1 but that didn't yield anything useful.
Here's the crash file for this segfault. I have a core dump but am having trouble getting gdb to be able to open it to inspect it.
See also rustls/rustls-ffi#49, hyperium/hyper#2438 (I wasn't sure which place to submit it.) Hyper suggested the issue may be in curl itself.
The text was updated successfully, but these errors were encountered: