Re: M1 macOS | Memory leaks at SSL that is used by libcurl/8.1.2 (SecureTransport)
Why should I use Asan or any other tool if I already used instrument leaks (part of XCode), which show the leaks? On Thu, Feb 1, 2024 at 11:14 PM Jeffrey Walton via curl-library < curl-library@lists.haxx.se> wrote: > On Thu, Feb 1, 2024 at 1:57 PM Josh WizardGuy via curl-library > wrote: > > > > Ah my bad. I didn't think it'd be that different with Mac users. > > Yeah, I think Valgrind needs to be trained for the M1's. I know > Valgrind will have to be mindful of the page size on the machine. M1's > use 16k page size, and that can cause a fair amount of trouble. > > I don't see any relevant bug reports for the M1's at the moment: > > * > https://bugs.kde.org/buglist.cgi?bug_status=__open__&content=Apple&product=valgrind > * > https://bugs.kde.org/buglist.cgi?bug_status=__open__&content=Silicon&product=valgrind > * > https://bugs.kde.org/buglist.cgi?bug_status=__open__&content=M1&product=valgrind > > But there does seem to be some chatter: > > * https://github.com/LouisBrunner/valgrind-macos/issues/56 > * > https://github.com/LouisBrunner/valgrind-macos/issues/56#issuecomment-1651811069 > > You may have to use Asan, Msan and the Leaks Tool until there is first > class Valgrind support. > > Jeff > > > On Wed, Jan 31, 2024, 1:29 AM mos via curl-library < > curl-library@lists.haxx.se> wrote: > >> > >> Why to use valgrind? Instruments shows the leaks. Also, if I calls this > code in a loop, the memory of the process raise for every call, > >> > >> > On 31 Jan 2024, at 4:06, Calvin Buckley via curl-library < > curl-library@lists.haxx.se> wrote: > >> > > >> > On Jan 30, 2024, at 6:56 PM, Josh WizardGuy via curl-library < > curl-library@lists.haxx.se> wrote: > >> >> U. Use valgrind? 🤷 > >> > > >> > That would be great advice... if Valgrind supported macOS/arm64. > -- > Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library > Etiquette: https://curl.se/mail/etiquette.html > -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: M1 macOS | Memory leaks at SSL that is used by libcurl/8.1.2 (SecureTransport)
On Thu, Feb 1, 2024 at 1:57 PM Josh WizardGuy via curl-library wrote: > > Ah my bad. I didn't think it'd be that different with Mac users. Yeah, I think Valgrind needs to be trained for the M1's. I know Valgrind will have to be mindful of the page size on the machine. M1's use 16k page size, and that can cause a fair amount of trouble. I don't see any relevant bug reports for the M1's at the moment: * https://bugs.kde.org/buglist.cgi?bug_status=__open__&content=Apple&product=valgrind * https://bugs.kde.org/buglist.cgi?bug_status=__open__&content=Silicon&product=valgrind * https://bugs.kde.org/buglist.cgi?bug_status=__open__&content=M1&product=valgrind But there does seem to be some chatter: * https://github.com/LouisBrunner/valgrind-macos/issues/56 * https://github.com/LouisBrunner/valgrind-macos/issues/56#issuecomment-1651811069 You may have to use Asan, Msan and the Leaks Tool until there is first class Valgrind support. Jeff > On Wed, Jan 31, 2024, 1:29 AM mos via curl-library > wrote: >> >> Why to use valgrind? Instruments shows the leaks. Also, if I calls this code >> in a loop, the memory of the process raise for every call, >> >> > On 31 Jan 2024, at 4:06, Calvin Buckley via curl-library >> > wrote: >> > >> > On Jan 30, 2024, at 6:56 PM, Josh WizardGuy via curl-library >> > wrote: >> >> U. Use valgrind? 🤷 >> > >> > That would be great advice... if Valgrind supported macOS/arm64. -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: M1 macOS | Memory leaks at SSL that is used by libcurl/8.1.2 (SecureTransport)
Ah my bad. I didn't think it'd be that different with Mac users. On Wed, Jan 31, 2024, 1:29 AM mos via curl-library < curl-library@lists.haxx.se> wrote: > Why to use valgrind? Instruments shows the leaks. Also, if I calls this > code in a loop, the memory of the process raise for every call, > > > Sent from my iPhone > > > On 31 Jan 2024, at 4:06, Calvin Buckley via curl-library < > curl-library@lists.haxx.se> wrote: > > > > On Jan 30, 2024, at 6:56 PM, Josh WizardGuy via curl-library < > curl-library@lists.haxx.se> wrote: > >> U. Use valgrind? 🤷 > > > > That would be great advice... if Valgrind supported macOS/arm64. > > -- > > Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library > > Etiquette: https://curl.se/mail/etiquette.html > -- > Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library > Etiquette: https://curl.se/mail/etiquette.html > -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: M1 macOS | Memory leaks at SSL that is used by libcurl/8.1.2 (SecureTransport)
Why to use valgrind? Instruments shows the leaks. Also, if I calls this code in a loop, the memory of the process raise for every call, Sent from my iPhone > On 31 Jan 2024, at 4:06, Calvin Buckley via curl-library > wrote: > > On Jan 30, 2024, at 6:56 PM, Josh WizardGuy via curl-library > wrote: >> U. Use valgrind? 🤷 > > That would be great advice... if Valgrind supported macOS/arm64. > -- > Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library > Etiquette: https://curl.se/mail/etiquette.html -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: M1 macOS | Memory leaks at SSL that is used by libcurl/8.1.2 (SecureTransport)
On Jan 30, 2024, at 6:56 PM, Josh WizardGuy via curl-library wrote: > U. Use valgrind? 🤷 That would be great advice... if Valgrind supported macOS/arm64. -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: M1 macOS | Memory leaks at SSL that is used by libcurl/8.1.2 (SecureTransport)
U. Use valgrind? 🤷
On Tue, Jan 30, 2024, 11:39 AM Mos Yud via curl-library <
curl-library@lists.haxx.se> wrote:
> Hi,
>
> Machine: M1 sonoma 14.1.1
>
> At my test I am using the shipped lib of curl, and its default used SSL,
> that is:
> curl 8.1.2 (x86_64-apple-darwin23.0) libcurl/8.1.2 (SecureTransport)
> LibreSSL/3.3.6 zlib/1.2.12 nghttp2/1.55.1
>
> I am getting memory leaks while running the following test:
>
> *void* CallCurl() {
>
> CURL *hnd;
>
> hnd = curl_easy_init();
>
> curl_easy_setopt(hnd, CURLOPT_URL, "https://www.google.com";);
>
> curl_easy_perform(hnd);
>
> curl_easy_cleanup(hnd);
>
> }
>
> I track the leaks with macOS instruments, and I see that all leaks are
> from SSL (I am using the default SSL that the shipped curl uses).
>
> Examples for the leaks stack frames:
> 1.
> serialize_ECPublicKey
> ECDSA_do_verify_new
> ossl_ecdsa_verify
> EVP_DigestVerifyFinal
> tls13_server_certificate_verify_recv
> tls13_handshake_perform
> tls13_legacy_connect
> ossl_connect_common
> ssl_cf_connect
> cf_setup_connect
> cf_hc_connect
> Curl_conn_connect
> multi_runsingle
> curl_multi_perform
> curl_easy_perform
> CallCurl()
> main
> start
>
> 2.
> ccMallocECCryptor
> CCECCryptorImportKey
> ECDSA_do_verify_new
> ossl_ecdsa_verify
> EVP_DigestVerifyFinal
> tls13_server_certificate_verify_recv
> tls13_handshake_perform
> tls13_legacy_connect
> ossl_connect_common
> ssl_cf_connect
> cf_setup_connect
> cf_hc_connect
> Curl_conn_connect
> multi_runsingle
> curl_multi_perform
> curl_easy_perform
> CallCurl()
> main
> start
>
> 3.
> ccMallocECCryptor
> CCECCryptorImportKey
> ECDSA_do_verify_new
> ossl_ecdsa_verify
> EVP_DigestVerifyFinal
> tls13_server_certificate_verify_recv
> tls13_handshake_perform
> tls13_legacy_connect
> ossl_connect_common
> ssl_cf_connect
> cf_setup_connect
> cf_hc_connect
> Curl_conn_connect
> multi_runsingle
> curl_multi_perform
> curl_easy_perform
> CallCurl()
> main
> start
>
> Any advice?
>
> Thx,
> Moshe.
> --
> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
> Etiquette: https://curl.se/mail/etiquette.html
>
--
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Re: M1 macOS | Memory leaks at SSL that is used by libcurl/8.1.2 (SecureTransport)
I didn't check it since I assumed I linked only with libcurl.dylib. If i
use this call, i need to link also with openssl.
According to curl documentation curl_easy_cleanup should clean all memory,
and its sounds strange that macOS is shifted with a curl that expose memory
leaks.
I also tested with curl 8.5.0 (aarch64-apple-darwin23.1.0) libcurl/8.5.0
SecureTransport zlib/1.2.12, and didn't see these leaks.
On Tue, Jan 30, 2024 at 9:59 PM Ray Satiro via curl-library <
curl-library@lists.haxx.se> wrote:
> On 1/30/2024 11:39 AM, Mos Yud via curl-library wrote:
>
> Machine: M1 sonoma 14.1.1
>
> At my test I am using the shipped lib of curl, and its default used SSL,
> that is:
> curl 8.1.2 (x86_64-apple-darwin23.0) libcurl/8.1.2 (SecureTransport)
> LibreSSL/3.3.6 zlib/1.2.12 nghttp2/1.55.1
>
> I am getting memory leaks while running the following test:
>
> *void* CallCurl() {
>
> CURL *hnd;
>
> hnd = curl_easy_init();
>
> curl_easy_setopt(hnd, CURLOPT_URL, "https://www.google.com";);
>
> curl_easy_perform(hnd);
>
> curl_easy_cleanup(hnd);
>
> }
>
> I track the leaks with macOS instruments, and I see that all leaks are
> from SSL (I am using the default SSL that the shipped curl uses).
>
>
> What happens if you call OPENSSL_cleanup() before exit?
>
>
> --
> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
> Etiquette: https://curl.se/mail/etiquette.html
>
--
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Re: M1 macOS | Memory leaks at SSL that is used by libcurl/8.1.2 (SecureTransport)
On 1/30/2024 11:39 AM, Mos Yud via curl-library wrote:
Machine: M1 sonoma 14.1.1
At my test I am using the shipped lib of curl, and its default used
SSL, that is:
curl 8.1.2 (x86_64-apple-darwin23.0) libcurl/8.1.2 (SecureTransport)
LibreSSL/3.3.6 zlib/1.2.12 nghttp2/1.55.1
I am getting memory leaks while running the following test:
*void*CallCurl() {
CURL*hnd;
hnd = curl_easy_init();
curl_easy_setopt(hnd, CURLOPT_URL, "https://www.google.com";);
curl_easy_perform(hnd);
curl_easy_cleanup(hnd);
}
I track the leaks with macOS instruments, and I see that all leaks are
from SSL (I am using the default SSL that the shipped curl uses).
What happens if you call OPENSSL_cleanup() before exit?
--
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Re: M1 macOS | Memory leaks at SSL that is used by libcurl/8.1.2 (SecureTransport)
The leaks are checked after curl_global_cleanup(). I haven't checked it yet on release 8.5.0. On Tue, Jan 30, 2024 at 7:18 PM Dan Fandrich via curl-library < curl-library@lists.haxx.se> wrote: > Is the code calling curl_global_cleanup() before checking for leaks? Does > this happen on the latest curl releae (8.5.0)? > -- > Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library > Etiquette: https://curl.se/mail/etiquette.html > -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: M1 macOS | Memory leaks at SSL that is used by libcurl/8.1.2 (SecureTransport)
Is the code calling curl_global_cleanup() before checking for leaks? Does this happen on the latest curl releae (8.5.0)? -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
M1 macOS | Memory leaks at SSL that is used by libcurl/8.1.2 (SecureTransport)
Hi,
Machine: M1 sonoma 14.1.1
At my test I am using the shipped lib of curl, and its default used SSL,
that is:
curl 8.1.2 (x86_64-apple-darwin23.0) libcurl/8.1.2 (SecureTransport)
LibreSSL/3.3.6 zlib/1.2.12 nghttp2/1.55.1
I am getting memory leaks while running the following test:
*void* CallCurl() {
CURL *hnd;
hnd = curl_easy_init();
curl_easy_setopt(hnd, CURLOPT_URL, "https://www.google.com";);
curl_easy_perform(hnd);
curl_easy_cleanup(hnd);
}
I track the leaks with macOS instruments, and I see that all leaks are from
SSL (I am using the default SSL that the shipped curl uses).
Examples for the leaks stack frames:
1.
serialize_ECPublicKey
ECDSA_do_verify_new
ossl_ecdsa_verify
EVP_DigestVerifyFinal
tls13_server_certificate_verify_recv
tls13_handshake_perform
tls13_legacy_connect
ossl_connect_common
ssl_cf_connect
cf_setup_connect
cf_hc_connect
Curl_conn_connect
multi_runsingle
curl_multi_perform
curl_easy_perform
CallCurl()
main
start
2.
ccMallocECCryptor
CCECCryptorImportKey
ECDSA_do_verify_new
ossl_ecdsa_verify
EVP_DigestVerifyFinal
tls13_server_certificate_verify_recv
tls13_handshake_perform
tls13_legacy_connect
ossl_connect_common
ssl_cf_connect
cf_setup_connect
cf_hc_connect
Curl_conn_connect
multi_runsingle
curl_multi_perform
curl_easy_perform
CallCurl()
main
start
3.
ccMallocECCryptor
CCECCryptorImportKey
ECDSA_do_verify_new
ossl_ecdsa_verify
EVP_DigestVerifyFinal
tls13_server_certificate_verify_recv
tls13_handshake_perform
tls13_legacy_connect
ossl_connect_common
ssl_cf_connect
cf_setup_connect
cf_hc_connect
Curl_conn_connect
multi_runsingle
curl_multi_perform
curl_easy_perform
CallCurl()
main
start
Any advice?
Thx,
Moshe.
--
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
