El mié, 10 feb 2021 a las 16:10, Groke, Paul (<paul.gr...@dynatrace.com>)
escribió:
> From: curl-library <curl-library-boun...@cool.haxx.se> On Behalf Of
> Adrián Gimeno Balaguer via curl-library
> Sent: Mittwoch, 10. Februar 2021 13:36
> To: curl-library@cool.haxx.se
> >
> > 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/libc.so.6
> > (gdb) bt
> > #0 0x00007ff9f8cddaec in free () from /lib64/libc.so.6
> > #1 0x00007ff9f984e3a1 in pthread_create@@GLIBC_2.2.5 () from
> /lib64/libpthread.so.0
> > #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?
Thanks,
--
*Adrián*
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
