Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
I did this
Installed esniper on OpenBSD 6.4-current, which is using curl_easy_perform.
I expected the following
No error, but instead I got:
Program received signal SIGSEGV, Segmentation fault.
This is referenced in https://sourceforge.net/p/esniper/bugs/767
The executed action is a GET, but it segfaults if CURLOPT_POSTFIELDSIZE is not set to 0. To my knowledge, it should not even go there if the request is a GET.
curl 7.63.0 (x86_64-unknown-openbsd6.4) libcurl/7.63.0 LibreSSL/2.9.0 zlib/1.2.3 nghttp2/1.36.0
OpenBSD 6.4-current (also segfaults in OpenBSD 6.4)
If you set an option like
I agree that ideally libcurl should just ignore that pointer in this case, but I don't think that's a good reason for an application to keep a stale pointer set for curl. PR coming up.
... since that data won't be used in the request anyway. Fixes #3548 Reported-by: Renaud Allard
Just to clarify: The original code does not contain a POSTFIELDS !
This code crashes on BSD.
renaudallard then inserted
to solve those crashes (https://sourceforge.net/p/esniper/bugs/767/)
That's even more weird. curl allocates the entire handle with calloc so it is cleared from the beginning and thus the pointer is NULLed internally from the beginning.
So if you can provide a smaller libcurl example that can make this happen without setting POSTFIELDS then I'm very curious!
Maybe the reason for the segmentation fault is, that a previous call to the function 'httpRequest' uses the requerstType = POST. The pointer set by this previous call using CURLOPT_POSTFIELDS is only valid during is call and was been freed by the caller. But from my point of view an invalid pointer to CURLOPT_POSTFIELDS must not have any impact to calls using GET.
That's a very slippery slope and I will not make any guarantees that this is safe. #3549 tries to make it better, but passing in a stale pointer to curl is wrong and bad no matter which option combination you're using.