Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Killed!
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: XSLT2.0 via curl-library <curl-library_at_cool.haxx.se>
Date: Sat, 24 Jul 2021 09:15:22 +0200
Hello,
Have you heard of any instance when the use of libcurl would "kill"
-directly or indirectly- the calling program?
That is what I get with my program on my Raspberry Pi.
libcurl/7.64.0 (arm-unknown-linux-gnueabihf) OpenSSL/1.1.1d (32bits)
When the program is run with my own socket code, it exhibits some
strange behaviour (my socket code is very basic) but keeps running.
The same program has a branch using libcurl (depending on the file name)
and keeps being "killed" almost systematically.
That might also be triggered by a kernel "bug". At some point the kernel
continues to send readaheads but forgets the response and asks for the
same piece of data again! This triggers in my program new connections to
the same file, with different ranges, and is the point when it gets
"killed" when using libcurl.
I am suspecting, with numerous new connections happening "in parallel",
that something would not be thread-safe, but since in this case the test
is with plain http (no SSL/TLS), the only idea would be DNS resolution.
This version of libcurl on 32 bits Raspberry Pi is the one that "bugs"
with time counters -stuck at 35:42-. You already kindly gave me pointers
to those patches and I posted to Raspberry Pi OS bug tracker, but they
don't seem eager to fix!..
Any idea about this "killed" when using libcurl?
(Program does not crash but ends with the message "Killed" and exit code
137 = 128 + 9, so signal 9: Kill)
Cheers
Alain
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-07-24
Date: Sat, 24 Jul 2021 09:15:22 +0200
Hello,
Have you heard of any instance when the use of libcurl would "kill"
-directly or indirectly- the calling program?
That is what I get with my program on my Raspberry Pi.
libcurl/7.64.0 (arm-unknown-linux-gnueabihf) OpenSSL/1.1.1d (32bits)
When the program is run with my own socket code, it exhibits some
strange behaviour (my socket code is very basic) but keeps running.
The same program has a branch using libcurl (depending on the file name)
and keeps being "killed" almost systematically.
That might also be triggered by a kernel "bug". At some point the kernel
continues to send readaheads but forgets the response and asks for the
same piece of data again! This triggers in my program new connections to
the same file, with different ranges, and is the point when it gets
"killed" when using libcurl.
I am suspecting, with numerous new connections happening "in parallel",
that something would not be thread-safe, but since in this case the test
is with plain http (no SSL/TLS), the only idea would be DNS resolution.
This version of libcurl on 32 bits Raspberry Pi is the one that "bugs"
with time counters -stuck at 35:42-. You already kindly gave me pointers
to those patches and I posted to Raspberry Pi OS bug tracker, but they
don't seem eager to fix!..
Any idea about this "killed" when using libcurl?
(Program does not crash but ends with the message "Killed" and exit code
137 = 128 + 9, so signal 9: Kill)
Cheers
Alain
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-07-24