libcurl crash

[GoogleCodeExporter]

see http://curl.haxx.se/mail/lib-2008-09/0197.html

it is affecting trg.  what is bizarre is that none of the 3 rpc threads have 
any traffic outstanding, so this is due to some dns lookup in the main thread?? 
 the app had been running minimized for several hours when this happened.

Program received signal SIGABRT, Aborted.
0x00007ffff52773a5 in __GI_raise (sig=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:64
64      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
        in ../nptl/sysdeps/unix/sysv/linux/raise.c
(gdb) 
(gdb) info thread
  Id   Target Id         Frame 
  4    Thread 0x7fffec46f700 (LWP 7735) "transmission-re" pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
  3    Thread 0x7fffecc70700 (LWP 7734) "transmission-re" pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
  2    Thread 0x7fffed471700 (LWP 7733) "transmission-re" pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
* 1    Thread 0x7ffff7fc4960 (LWP 7730) "transmission-re" 0x00007ffff52773a5 in 
__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
(gdb) bt
#0  0x00007ffff52773a5 in __GI_raise (sig=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff527ab0b in __GI_abort () at abort.c:92
#2  0x00007ffff52af113 in __libc_message (do_abort=2, fmt=0x7ffff539e61e "*** 
%s ***: %s terminated\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
#3  0x00007ffff53397f7 in __GI___fortify_fail (msg=0x7ffff539e5dd "longjmp 
causes uninitialized stack frame") at fortify_fail.c:32
#4  0x00007ffff5339789 in ____longjmp_chk () at 
../sysdeps/unix/sysv/linux/x86_64/____longjmp_chk.S:86
#5  0x00007ffff53396f3 in __longjmp_chk (env=0x7ffff5a57bc0, val=<optimized 
out>) at ../setjmp/longjmp.c:40
#6  0x00007ffff580acc5 in alarmfunc () from 
/usr/lib/x86_64-linux-gnu/libcurl.so.4
#7  <signal handler called>
#8  0x00007ffff5316773 in __GI___poll (fds=<optimized out>, nfds=<optimized 
out>, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87
#9  0x00007ffff5a9d058 in g_main_context_poll (n_fds=3, fds=0x7aadd0, 
timeout=59877, context=0x67d9f0, priority=<optimized out>)
    at /build/buildd/glib2.0-2.29.92/./glib/gmain.c:3402
#10 g_main_context_iterate (context=0x67d9f0, block=<optimized out>, 
dispatch=1, self=<optimized out>) at 
/build/buildd/glib2.0-2.29.92/./glib/gmain.c:3084
#11 0x00007ffff5a9d882 in g_main_loop_run (loop=0x8abee0) at 
/build/buildd/glib2.0-2.29.92/./glib/gmain.c:3297
#12 0x00007ffff6fe8dc7 in IA__gtk_main () at 
/build/buildd/gtk+2.0-2.24.6/gtk/gtkmain.c:1259
#13 0x000000000040cbd8 in main (argc=1, argv=0x7fffffffe138) at main.c:174

Original issue reported on code.google.com by reardo...@gmail.com on 21 Sep 2011 at 4:21

[GoogleCodeExporter]

Issue 45 has been merged into this issue.

Original comment by a...@eth0.org.uk on 21 Sep 2011 at 4:38

[GoogleCodeExporter]

Not much I can do about this from what I've read. Compiling libcurl with c-ares 
for async DNS resolution seems to be the solution, and most distros should move 
to this eventually.

Original comment by a...@eth0.org.uk on 21 Sep 2011 at 4:49

[GoogleCodeExporter]

I guess there is no way to handle SIGABRT in a contextual way, iow when it's 
triggered by libcurl in this scenario?

Original comment by reardo...@gmail.com on 21 Sep 2011 at 7:11

[GoogleCodeExporter]

I don't think so, also see https://bugzilla.redhat.com/show_bug.cgi?id=539809

Btw, if you have Windows, check out the win32 version I just uploaded. :)

Original comment by a...@eth0.org.uk on 21 Sep 2011 at 7:58

[GoogleCodeExporter]

For several days I've been running with my own libcurl build (based 7.22), 
using libc-ares for async dns.  Runs smoothly and hasn't crashed since.  Noting 
here in case others stumble onto this bug.

Original comment by reardo...@gmail.com on 23 Sep 2011 at 2:15

[GoogleCodeExporter]

Original comment by a...@eth0.org.uk on 1 Oct 2011 at 12:04

• Changed state: Fixed

[GoogleCodeExporter]

Yave same issue on ubuntu-12.10-server-amd64 with libcurl4-openssl-dev on 
multiple repeaded requests in multithread application. Here is stack trace 
(looks same as in initial message):

0x00007ffff6720425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007ffff6720425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff6723b8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007ffff675e39e in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007ffff67f4807 in __fortify_fail ()
   from /lib/x86_64-linux-gnu/libc.so.6
#4  0x00007ffff67f477d in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#5  0x00007ffff67f46e3 in __longjmp_chk () from /lib/x86_64-linux-gnu/libc.so.6
#6  0x00007ffff6fccff5 in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#7  <signal handler called>
#8  0x00007ffff67a983d in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6
#9  0x00007ffff67d7774 in usleep () from /lib/x86_64-linux-gnu/libc.so.6
#10 0x0000000000436802 in FDServer::MainLoop (this=0x11682d0)
    at ../../src/fdserver/FDServer.cpp:239
#11 0x0000000000436aba in FDServer::Run (this=0x11682d0)
    at ../../src/fdserver/FDServer.cpp:201
#12 0x0000000000403d09 in main () at ../../src/fdserver/main.cpp:25

Original comment by alexande...@gmail.com on 1 Mar 2013 at 1:13