I'm still getting failures for some of these torture tests here. My build is
./configure --disable-shared --disable-ipv6 --enable-ares --enable-debug --without-ssl

This patch fixes failures on test 20 (actually free(0) again):

diff -d -u -3 -r1.2 ares__get_hostent.c
--- ares__get_hostent.c 2 Feb 2004 15:59:35 -0000 1.2
+++ ares__get_hostent.c 26 May 2004 15:33:14 -0000
@@ -143,25 +143,29 @@
       free(line);
       return ARES_SUCCESS;
     }
- free(line);
+ if (line)
+ free(line);
 
   if (status == ARES_SUCCESS)
     {
       /* Memory allocation failure; clean up. */
       if (hostent)
         {
- free((char *) hostent->h_name);
+ if (hostent->h_name)
+ free((char *) hostent->h_name);
           if (hostent->h_aliases)
             {
               for (alias = hostent->h_aliases; *alias; alias++)
                 free(*alias);
             }
- free(hostent->h_aliases);
- if (hostent->h_addr_list)
+ if (hostent->h_aliases)
+ free(hostent->h_aliases);
+ if (hostent->h_addr_list && hostent->h_addr_list[0])
             free(hostent->h_addr_list[0]);
- free(hostent->h_addr_list);
+ if (hostent->h_addr_list)
+ free(hostent->h_addr_list);
+ free(hostent);
         }
- free(hostent);
       return ARES_ENOMEM;
     }

__________________________________________________________________________

I'm now stuck on case 43, alloc 51. runtests.pl gave the following output:

$ ./runtests.pl -t 43
********* System characteristics ********
* curl 7.12.0-CVS (i686-pc-linux-gnu)
* libcurl/7.12.0-CVS zlib/1.2.1.1 c-ares/1.2.0
* Host: zamez
* System: Linux zamez 2.6.4 #1 Tue Mar 23 12:29:59 GMT 2004 i686 GNU/Linux
* Server SSL: OFF
* libcurl SSL: OFF
* libcurl debug: ON
* valgrind: OFF
*****************************************
test 043...[HTTP Location: following over HTTP proxy]
 66 allocations to make fail
** MEMORY FAILURE
Not recognized prefix line: FD url.c:14
Leak detected: memory still allocated: 35869 bytes
At 809832c, there's 12 bytes.
 allocated by llist.c:65
...
 Failed on alloc number 51 in test.
 invoke with -t51 to repeat this single case.

Note the "Not recognized prefix line: FD url.c:14". The last line of memdump
was incomplete. Starting sws and running the test by hand revealed why:

$ CURL_MEMLIMIT=51 ../src/curl --include -v http://127.0.0.1:8999/want/43 -L -x 127.0.0.1:8999
* About to connect() to 127.0.0.1 port 8999
* Connected to 127.0.0.1 (127.0.0.1) port 8999
> GET http://127.0.0.1:8999/want/43 HTTP/1.1
User-Agent: curl/7.12.0-CVS (i686-pc-linux-gnu) libcurl/7.12.0-CVS zlib/1.2.1.1 c-ares/1.2.0
Host: 127.0.0.1:8999
Pragma: no-cache
Accept: */*
 
< HTTP/1.1 301 This is a weirdo text message
HTTP/1.1 301 This is a weirdo text message
< Date: Thu, 09 Nov 2010 14:49:00 GMT
Date: Thu, 09 Nov 2010 14:49:00 GMT
< Server: test-server/fake
Server: test-server/fake
< Location: data/430002.txt?coolsite=yes
Location: data/430002.txt?coolsite=yes
< Connection: close
Connection: close
 
* Closing connection #0
* Issue another request to this URL: 'http://127.0.0.1:8999/want/data/430002.txt?coolsite=yes'
LIMIT url.c:2835 strdup reached memlimit
LIMIT url.c:2972 strdup reached memlimit
LIMIT url.c:2973 strdup reached memlimit
Segmentation fault

I haven't looked why the test script loses this (it's not in log/stderr43).
Running under gdb doesn't cause the seg fault for some reason, but valgrind
does.

#0 strlen (str=0x0) at mac_replace_strmem.c:189
#1 0x0805af4b in create_hostcache_id (server=0x0, port=8999, entry_len=0x4fffdc10) at hostip.c:204
#2 0x0805b286 in Curl_resolv (conn=0x3c18b5d0, hostname=0x0, port=8999, entry=0x4fffe428) at hostip.c:401
#3 0x08061fe4 in CreateConnection (data=0x3c181314, in_connect=0x4fffe49c, addr=0x4fffe460, async=0x4fffe493 "") at url.c:3189
#4 0x08062371 in Curl_connect (data=0x3c181314, in_connect=0x4fffe49c, asyncp=0x4fffe493 "") at url.c:3345
#5 0x080696a2 in Curl_perform (data=0x3c181314) at transfer.c:1953
#6 0x0805829e in curl_easy_perform (curl=0x3c181314) at easy.c:378
#7 0x0804fb71 in operate (config=0x4fffe890, argc=7, argv=0x4fffea64) at main.c:3427
#8 0x0804ff7b in main (argc=7, argv=0x4fffea64) at main.c:3575

Obviously the server and hostname parameters are wrong. I don't know the
code well enough to get any further easily. Daniel, can you reproduce this?

James
Received on 2004-05-26