I can confirm that this happened to a recently updated linux box once (the first time). And then 30 times it does not happen. I found that a way to make the problem appear is to restart the network service.

Following Corion's investigation, the perl_curl_call() function is then typedef'ed into PERL_CURL_CALL which can be found being called in a few places: find . -type f -exec grep -H -i 'perl_curl_call' \{\} \; which you can investigate manually.

Additionally, add code to print a stacktrace each time said function is called. I used https://stackoverflow.com/questions/105659/how-can-one-grab-a-stack-trace-in-c (the C part) or try https://gist.github.com/mooware/1198160. Unfortunately in my case the stacktrace does not contain function names but relative addresses from the object file. Theoretically, one can translate these to function names with other tools that linux provides generously, e.g. addr2line, objdump.

This is the patch to the modified Curl.xs for printing a stacktrace:

--- ../oo/Net-Curl-0.56/Curl.xs    2022-08-16 08:44:34.000000000 +0300
+++ Curl.xs    2024-11-21 12:11:53.087671081 +0200
@@ -4,6 +4,7 @@
  * Perl interface for libcurl. Check out the file README for more inf
+o.
  */
 
+#include <execinfo.h>
 /*
  * Copyright (C) 2000, 2001, 2002, 2005, 2008 Daniel Stenberg, Cris B
+ailiff, et al.
  * Copyright (C) 2011-2015 Przemyslaw Iskra.
@@ -278,6 +279,14 @@
     SV *olderrsv = NULL;
     int method_call = 0;
 
+void* callstack[128];
+int frames = backtrace(callstack, 128);
+char** strs = backtrace_symbols(callstack, frames);
+for (int I = 0; I < frames; ++I) {
+    printf("STACKTRACE: %s\n", strs[I]);
+}
+free(strs);
+
     if ( ! cb->func || ! SvOK( cb->func ) ) {
         warn( "callback function is not set\n" );
         return -1;
[download]

This is the stacktrace for my situation, not very helpful without function names though:

TRACE 6: 'Operation was aborted by an application callback'STACKTRACE:
+ blib/arch/auto/Net/Curl/Curl.so(+0x10d09) [0x7f5f16740d09]
STACKTRACE: blib/arch/auto/Net/Curl/Curl.so(+0x11d7b) [0x7f5f16741d7b]
STACKTRACE: /usr/lib64/libcurl.so.4(+0x51b84) [0x7f5f166cdb84]
STACKTRACE: /usr/lib64/libcurl.so.4(+0x5542b) [0x7f5f166d142b]
STACKTRACE: /usr/lib64/libcurl.so.4(curl_multi_perform+0x105) [0x7f5f1
+66d4265]
STACKTRACE: blib/arch/auto/Net/Curl/Curl.so(+0xb834) [0x7f5f1673b834]
STACKTRACE: perl() [0x4fdd6c]
STACKTRACE: perl(Perl_runops_standard+0x13) [0x4f4023]
STACKTRACE: perl(perl_run+0x4b8) [0x43ef78]
STACKTRACE: perl(main+0x102) [0x419372]
STACKTRACE: /usr/lib64/libc.so.6(+0x2814a) [0x7f5f1678014a]
STACKTRACE: /usr/lib64/libc.so.6(__libc_start_main+0x8b) [0x7f5f167802
+0b]
STACKTRACE: perl(_start+0x25) [0x4193b5]
[download]

One needs to investigate the function names for e.g. +0x5542b of libcurl and 0x11d7b of Curl.o. Note that you will need to observe the make's output to find out how to recreate Curl.o as this is deleted at the end.

And another alternative is to compile libcurl and this module with -g and run perl through gdb. You do not need to recompile perl with -g.

Also, note that when compiling current version of this module it complains about a lot of deprecations.

few hours Edit: The version of my libcurl is 8.2.1. According to the https://metacpan.org/dist/Net-Curl/changes, the latest (v0.56) Net::Curl::Multi has been adjusted for libcurl 8.7.1. So, it is worth retrying with exactly that libcurl version.

It also fails with libcurl 8.9.1

bw, bliako