cURL / Mailing Lists / curl-library / Single Mail


Re: multi_runsingle referencing freed connection

From: Daniel Johnson <>
Date: Sat, 24 Feb 2007 09:04:57 -0500

Hash: SHA1

On Feb 23, 2007, at 12:05 PM, Daniel Johnson wrote:

> On Feb 20, 2007, at 4:25 PM, Daniel Stenberg wrote:
>> On Tue, 20 Feb 2007, Daniel Johnson wrote:
>>>> Thanks for your heads up. I'll see what I can do. Unfortunately
>>>> I have no Mac OS X machine to work on so it might be a bit
>>>> tricky for me to track this down...
>>> When I force curl to use poll instead of select, 531 passes but
>>> 530 still fails. I'll be glad to help track it down if you have
>>> any suggestions of what to look at.
>> Test 531 seems to fail since there are some strange left-overs
>> from the 530 failure. That looks like a test system bug.
>> The test 530 failure is related to the change I did that marks
>> HTTP connections as re-usable directly after connect and then made
>> the ConnectionExists() function check that bit only - previously
>> it checked if it was not for reuse AND part of a pipeline to make
>> it get skipped.
>> My guess is that the connections don't connect immediately on Mac
>> OS X so that lib530.c fires them off too rapidly and thus they are
>> all stilled marked as not reusable when attempted for re-use
>> (since the HTTP-specific connect part that marks them as re-usable
>> hasn't be run yet).
>> Alas, I believe the libcurl code is fine but the test code doesn't
>> quite test exactly what we (I) want and we probably need to figure
>> out a way to make the first connection connect properly first
>> before the following connections should be allowed to be "let
>> through".
> I've got some more information about this. Test 530 usually fails,
> but occasionally it does pass, such as during my Feb 22 autobuild.
> I then reran the tests and it failed again. I even had it crash
> once. This is the stack trace from the crash log:
> - ---------
> Exception: EXC_BAD_ACCESS (0x0001)
> Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000
> Thread 0 Crashed:
> 0 libcurl.4.dylib 0x00232a40 Curl_hash_clean + 35 (hash.c:244)
> 1 libcurl.4.dylib 0x00232b47 Curl_hash_destroy + 29 (hash.c:282)
> 2 libcurl.4.dylib 0x0021a1c5 Curl_close + 599 (url.c:307)
> 3 libcurl.4.dylib 0x0022f869 curl_easy_cleanup + 29 (easy.c:506)
> 4 lib530 0x00002ba5 test + 1463 (lib530.c:156)
> 5 lib530 0x00002d23 main + 281 (first.c:74)
> 6 lib530 0x000025d2 _start + 216
> 7 lib530 0x000024f9 start + 41
> Thread 0 crashed with X86 Thread State (32-bit):
> eax: 0x00000000 ebx: 0x00232a29 ecx: 0x00000001 edx: 0x00000000
> edi: 0x00047f64 esi: 0x45de6f74 ebp: 0xbfffeaf8 esp: 0xbfffead0
> ss: 0x0000001f efl: 0x00010246 eip: 0x00232a40 cs: 0x00000017
> ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037
> - ---------

Just to add some more data, in my autobuild today (Feb 24) test 530
failed and crashed with a back trace identical to the one above. The
build log is very different from when it fails but doesn't crash.
Something is definitely stomping on the stack somewhere.


Version: GnuPG v1.4.6 (Darwin)

Received on 2007-02-24