Więc mam bardzo prosty przykład rozmowy z serwerem facebooka przez https, ale valgrind narzeka smutno. Zakładam więc, że nie ustawiam czegoś niepoprawnie ... czy ktoś wie, co robię źle?valgrind zgłasza problemy z libcurl podczas korzystania z https
Oto mój kod:
#include <string>
#include <iostream>
#include <curl/curl.h>
size_t write_fn_impl(void* ptr, size_t size, size_t nmemb, void * data)
{
std::string * result = static_cast<std::string*>(data);
*result += std::string((char*)ptr, size*nmemb);
return size*nmemb;
}
int main()
{
std::string url_full="https://graph.facebook.com/me";
std::string useragent = "Facebook API C++ Client (curl)";
CURL * ch_ = curl_easy_init();
char error_buffer[CURL_ERROR_SIZE];
curl_easy_setopt(ch_, CURLOPT_ERRORBUFFER, error_buffer);
curl_easy_setopt(ch_, CURLOPT_WRITEFUNCTION, &write_fn_impl);
std::string result;
curl_easy_setopt(ch_, CURLOPT_WRITEDATA, &result);
int id = 1;
curl_easy_setopt(ch_, CURLOPT_VERBOSE, id);
curl_easy_setopt(ch_, CURLOPT_URL, url_full.c_str());
curl_easy_setopt(ch_, CURLOPT_USERAGENT, useragent.c_str());
curl_easy_setopt(ch_, CURLOPT_CONNECTTIMEOUT, 10);
curl_easy_setopt(ch_, CURLOPT_TIMEOUT, 30);
curl_easy_perform(ch_);
curl_easy_cleanup(ch_);
std::cout<< result<<std::endl;
}
A co valgrind mówi się:
==14149== Memcheck, a memory error detector
==14149== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==14149== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info
==14149== Command: ./a.out
==14149==
* About to connect() to graph.facebook.com port 443 (#0)
* Trying 66.220.146.47... * connected
* Connected to graph.facebook.com (66.220.146.47) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
==14149== Syscall param write(buf) points to uninitialised byte(s)
==14149== at 0x4268113: __write_nocancel (in /lib/tls/i686/cmov/libc-2.10.1.so)
==14149== by 0x44A5A8E: BIO_write (in /lib/i686/cmov/libcrypto.so.0.9.8)
==14149== by 0x43E49B8: ssl23_write_bytes (in /lib/i686/cmov/libssl.so.0.9.8)
==14149== by 0x43E39AB: ssl23_connect (in /lib/i686/cmov/libssl.so.0.9.8)
==14149== by 0x43F0D49: SSL_connect (in /lib/i686/cmov/libssl.so.0.9.8)
==14149== by 0x4050EB0: ossl_connect_common (in /usr/lib/libcurl.so.4.1.1)
==14149== by 0x4052202: Curl_ossl_connect (in /usr/lib/libcurl.so.4.1.1)
==14149== by 0x406597F: Curl_ssl_connect (in /usr/lib/libcurl.so.4.1.1)
==14149== by 0x403FF1B: Curl_http_connect (in /usr/lib/libcurl.so.4.1.1)
==14149== by 0x4046F6D: Curl_protocol_connect (in /usr/lib/libcurl.so.4.1.1)
==14149== by 0x404C396: Curl_connect (in /usr/lib/libcurl.so.4.1.1)
==14149== by 0x4059B23: Curl_perform (in /usr/lib/libcurl.so.4.1.1)
==14149== Address 0x47e92df is 15 bytes inside a block of size 21,848 alloc'd
==14149== at 0x4024C1C: malloc (vg_replace_malloc.c:195)
==14149== by 0x4446EFD: ??? (in /lib/i686/cmov/libcrypto.so.0.9.8)
==14149== by 0x444755B: CRYPTO_malloc (in /lib/i686/cmov/libcrypto.so.0.9.8)
==14149== by 0x44A4EF7: BUF_MEM_grow (in /lib/i686/cmov/libcrypto.so.0.9.8)
==14149== by 0x43E3BAB: ssl23_connect (in /lib/i686/cmov/libssl.so.0.9.8)
==14149== by 0x43F0D49: SSL_connect (in /lib/i686/cmov/libssl.so.0.9.8)
==14149== by 0x4050EB0: ossl_connect_common (in /usr/lib/libcurl.so.4.1.1)
==14149== by 0x4052202: Curl_ossl_connect (in /usr/lib/libcurl.so.4.1.1)
==14149== by 0x406597F: Curl_ssl_connect (in /usr/lib/libcurl.so.4.1.1)
==14149== by 0x403FF1B: Curl_http_connect (in /usr/lib/libcurl.so.4.1.1)
==14149== by 0x4046F6D: Curl_protocol_connect (in /usr/lib/libcurl.so.4.1.1)
==14149== by 0x404C396: Curl_connect (in /usr/lib/libcurl.so.4.1.1)
I stron więcej ....
ten artykuł był ciekawy, ale ignoruje fakt, że valgrind * nie w rzeczywistości znalezienia błędu * w OpenSSL. OpenSSL był (i prawdopodobnie nadal jest) opierając się na * niezdefiniowanym zachowaniu * jako źródle entropii, zamiast uzyskać entropię z legalnego źródła. Ten sam "bug", który został dodany do Debiana, równie dobrze mógł pojawić się na podstawie zmian w kompilatorze lub bibliotece, które spowodowały niezainicjowanie danych przez OpenSSL jako "mniej losowe". W skrócie, jeśli valgrind zgłasza takie problemy, prawie na pewno oznacza to, że kod jest * nieprawidłowy *, ale trywialna poprawka może być jeszcze gorsza. :-) –
@R Nie pamiętam szczegółów, ale myślę, że twoja interpretacja jest trochę wyłączona. Przypominam sobie, że nie polegali oni na pamięci niezainicjowanej, ale raczej naprawiono przypadkowo inne "prawdziwe" źródło entropii wraz z nim. Moje wspomnienia są niejasne ... ale najważniejsze jest: nie zadzieraj z OpenSSL. –
@MK: Z artykułu wynika, że problem ma więcej wspólnego z programiście próbującym naprawić "wykształconą domysły" niż cokolwiek innego. Jeśli lib przyszedł z odpowiednim plikiem tłumiącym valgrind, który zasygnalizował to zamierzonym działaniem (lub komentarzem w kodzie), lub jeśli deweloper sprawdził "błąd" z programistami OpenSSL i poprosił o radę, nie byłoby jakakolwiek sprawa. Morale tej historii: potrzeba więcej niż narzędzia do naprawienia błędów ... ale czy wszyscy już o tym nie wiedzieliśmy? –