Hi,
I pushed the proposed fix of setting CURLOPT_NOSIGNAL to 1. This
effectively makes libcurl lose its timeout ability for synchronous DNS
lookups. Asynchronous DNS lookups via the c-ares library are not
effected.
You backtrace shows a timeout of a synchronous DNS lookup, I think
(see the
Hi Matthias,
This can't be reproduced 100%. I reproduce this case twice. But when I set
the CURLOPT_NOSIGNAL to 1. I didn't find the similar
core again. And it seems that everything works well. What do you mean stuck
in a DNS lookup?
B.R.
Benjamin Wang
-Original Message-
From:
2012/9/23 Benjamin Wang (gendwang) gendw...@cisco.com:
Hi,
I found two core dumps generated in multi-thread scenarios in ESX part.
Case1: libcurl support multi-thread
core dump:
#12 0x2aaabea89712 in addbyter () from /usr/local/lib/libcurl.so.4
#13 0x2aaabea89b86 in
On Sun, Sep 23, 2012 at 03:32:52AM +, Benjamin Wang (gendwang) wrote:
Hi,
I found two core dumps generated in multi-thread scenarios in ESX part.
Case1: libcurl support multi-thread
core dump:
#12 0x2aaabea89712 in addbyter () from /usr/local/lib/libcurl.so.4
#13 0x2aaabea89b86
(curl-handle, CURLOPT_HEADER, 0);
B.R.
Benjamin Wang
-Original Message-
From: Daniel Veillard [mailto:veill...@redhat.com]
Sent: 2012年9月23日 16:52
To: Benjamin Wang (gendwang)
Cc: Matthias Bolte; libvir-list@redhat.com; Yang Zhou (yangzho)
Subject: Re: [libvirt] Two core dumps are generated
Hi,
I found two core dumps generated in multi-thread scenarios in ESX part.
Case1: libcurl support multi-thread
core dump:
#12 0x2aaabea89712 in addbyter () from /usr/local/lib/libcurl.so.4
#13 0x2aaabea89b86 in dprintf_formatf () from /usr/local/lib/libcurl.so.4
#14 0x2aaabea8b055
