2011-02-02 10 views
5

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 ....

Odpowiedz

4

MK jest częściowo poprawny. Valgrind rzuca dużo niepotrzebnych ostrzeżeń na temat OpenSSL. Ale w moim przypadku wypadki, które widziałem, wydawały się być spowodowane jakimś kłopotem z użyciem openSSL. W szczególności nie został poprawnie skonfigurowany do użytku wielowątkowego. Dokumenty curl pokrywają to, co musisz zrobić .. ale jakoś mi się to spóźniło)

W każdym razie heres pliku tłumienia, który pomógł mi go znaleźć .. może być przydatny dla kogoś .. Ale uważaj, prawdopodobnie nie robi ' złapać wszystko, czego chcesz złapać, i to pewnie łapie pewne rzeczy nie chcesz ...

{ 
    openssl-rand-write 
    Memcheck:Param 
    write(buf) 
    fun:__write_nocancel 
    fun:BIO_write 
    fun:ssl23_write_bytes 
    fun:ssl23_connect 
    fun:SSL_connect 
    fun:ossl_connect_common 
} 
{ 
    openssl-rand-write2 
    Memcheck:Param 
    write(buf) 
    fun:__write_nocancel 
    fun:BIO_write 
    fun:ssl3_write_pending 
    obj:/lib/i686/cmov/libssl.so.0.9.8 
    fun:ssl3_write_bytes 
    fun:ssl3_write 
    fun:SSL_write 
} 
{ 
    openssl-rand-write3 
    Memcheck:Param 
    write(buf) 
    fun:__write_nocancel 
    fun:BIO_write 
    ... 
    fun:ossl_connect_common 
} 
{ 
    openssl-rand-uninit_mod_inverse 
    Memcheck:Cond 
    fun:BN_mod_inverse 
    ... 
    obj:/lib/i686/cmov/libcrypto.so.0.9.8 
} 
{ 
    openssl-rand-uninit_div 
    Memcheck:Cond 
    fun:BN_div 
    ... 
    obj:/lib/i686/cmov/libcrypto.so.0.9.8 
} 
{ 
    openssl-uninit-padding 
    Memcheck:Cond 
    fun:RSA_padding_add_PKCS1_type_2 
    obj:/lib/i686/cmov/libcrypto.so.0.9.8 
} 
{ 
    openssl-uninit-ucmp 
    Memcheck:Cond 
    fun:BN_ucmp 
    obj:/lib/i686/cmov/libcrypto.so.0.9.8 
} 
{ 
    openssl-uninit-encrypt 
    Memcheck:Cond 
    obj:/lib/i686/cmov/libcrypto.so.0.9.8 
    fun:RSA_public_encrypt 
} 
{ 
    openssl-uninit-ssl3_read_bytes 
    Memcheck:Cond 
    fun:ssl3_read_bytes 
    fun:ssl3_read 
    fun:SSL_read 
} 
{ 
    openssl-uninit-get_finished 
    Memcheck:Cond 
    fun:ssl3_get_finished 
    fun:ssl3_connect 
    fun:SSL_connect 
    fun:ossl_connect_common 
} 
{ 
    openssl-uninit-read_bytes 
    Memcheck:Cond 
    ... 
    fun:ossl_connect_common 
} 
{ 
    openssl-value4-connect_common 
    Memcheck:Value4 
    ... 
    fun:ossl_connect_common 
} 
{ 
    openssl-uninit-encrypt 
    Memcheck:Cond 
    ...  
    fun:RSA_public_encrypt 
} 
1

Ostatni raz ktoś próbował upewnić OpenSSL biegnie pod czyste Zrobione złe rzeczy (tm): http://blogs.fsfe.org/tonnerre/archives/24

Więc po prostu zignorowałbym ostrzeżenia vlagrind dotyczące OpenSSL.

+1

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. :-) –

+0

@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. –

+0

@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? –