curl / Mailing Lists / curl-library / Single Mail
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.

Re: Periodic segfault in curl_easy_perform()

From: Adrián Gimeno Balaguer via curl-library <>
Date: Tue, 9 Mar 2021 15:23:59 +0100

El mié, 10 feb 2021 a las 16:10, Groke, Paul (<>)

> From: curl-library <> On Behalf Of
> Adrián Gimeno Balaguer via curl-library
> Sent: Mittwoch, 10. Februar 2021 13:36
> To:
> >
> > The program crashes after 5-10 minutes since startup (provided the
> periodic check always sends files) at curl_easy_perform() with the
> following stack trace:
> >
> > Program terminated with signal 11, Segmentation fault.
> > #0 0x00007ff9f8cddaec in free () from /lib64/
> > (gdb) bt
> > #0 0x00007ff9f8cddaec in free () from /lib64/
> > #1 0x00007ff9f984e3a1 in pthread_create_at__at_GLIBC_2.2.5 () from
> /lib64/
> > #2 0x00000000004b315c in Curl_thread_create ()
> Crashes in `free` usually mean there's heap corruption. And with heap
> corruptions, the stack-trace of the crash often has nothing to do with the
> actual bug. The most likely reasons for heap corruptions are out-of-bounds
> writes and use of dangling pointers. Daniel's suggestion to use
> valgrind/ASAN is a good one - those tools should help you find the cause.
> Count yourself lucky that you can repro the problem by just running the
> program for 5-10 minutes 😉
> The contents of this e-mail are intended for the named addressee only. It
> contains information that may be confidential. Unless you are the named
> addressee or an authorized designee, you may not copy or use it, or
> disclose it to anyone else. If you received it in error please notify us
> immediately and then destroy it. Dynatrace Austria GmbH (registration
> number FN 91482h) is a company registered in Linz whose registered office
> is at 4020 Linz, Austria, Am Fünfundzwanziger Turm 20

Hello again,

After making functional changes in my program, I'm running into a different
crash scenario.

Program seems to run fine when sending a file in development machine, but
now it always crashes on a test machine with identical environment:

Program terminated with signal 11, Segmentation fault.
#0 __GI___libc_free (mem=0x1) at malloc.c:2941
2941 if (chunk_is_mmapped(p)) /* release mmapped
memory. */
(gdb) bt full
#0 __GI___libc_free (mem=0x1) at malloc.c:2941
        ar_ptr = <optimized out>
        p = <optimized out>
        hook = 0x0
#1 0x00000000004b070f in Curl_free_request_state ()
No symbol table info available.
#2 0x00000000004b1032 in Curl_connect ()
No symbol table info available.
#3 0x00000000004a4fbd in multi_runsingle ()
No symbol table info available.
#4 0x00000000004a59fe in curl_multi_perform ()
No symbol table info available.
#5 0x000000000049cd73 in curl_easy_perform ()
No symbol table info available.

I already tried to run Valgrind to debug the other "5-10 minutes" reported
crash I had before but couldn't reach anything useful on the development
machine, since it just kept running.

Could this stack trace mean any well-known mistake on CURL in this case?

Otherwise. Considering the fact that apparently Valgrind is aimed to detect
memory leaks and it can't (easily?) detect the source code line/s that
might cause deferred UB errors, should I even bother to install and run it
on the test machine? If so, should I use any special parameters?



Received on 2021-03-09