There's a crash during the test phase of one of my autobuilds, on the
Linux 2.6 i686 icc 9.1 (Debian SID 32-bit SMP).
Sorry I didn't notice it earlier, it's due to the 16MB logfiles which
didn't go through the mail system and thus weren't visible at the
autobuild page.

The combination that crashes is:
Compiler: icc 9.1
Options: ./configure --with-ssl --disable-debug --disable-ipv6

Tests are crashing, e.g. the first one:

 ./runtests.pl -v 1
********* System characteristics ********
* curl 7.19.0-CVS (i686-pc-linux-gnu)
* libcurl/7.19.0-CVS OpenSSL/0.9.8g zlib/1.2.3.3 libidn/0.6.5 libssh2/0.18
* Features: IDN Largefile NTLM SSL libz
* Host:
* System: Linux 2.6.19.2 #1 SMP PREEMPT Wed Jan 24 13:28:18 CET 2007
i686 GNU/Linux
* Server SSL: ON
* libcurl SSL: ON
* libcurl debug: OFF
* valgrind: ON
* HTTP IPv6 OFF
* FTP IPv6 OFF
* HTTP port: 8990
* FTP port: 8992
* FTP port 2: 8995
* FTPS port: 8993
* HTTPS port: 8991
* TFTP port: 8997
* SCP/SFTP port: 8999
* SOCKS port: 9000
* SSL library: OpenSSL
* Libtool lib: OFF
*****************************************
startnew: perl -I. ./httpserver.pl -p .http.pid 8990
CMD; ../src/curl --max-time 13 --output log/verifiedserver --insecure
--silent --verbose --globoff "http://127.0.0.1:8990/verifiedserver"
2>log/verifyhttp
sh: line 1: 30999 Segmentation fault (core dumped) ../src/curl
--max-time 13 --output log/verifiedserver --insecure --silent
--verbose --globoff "http://127.0.0.1:8990/verifiedserver"
2>log/verifyhttp
RUN: curl command returned 139
RUN: * About to connect() to 127.0.0.1 port 8990 (#0)
RUN: * Trying 127.0.0.1... connected
RUN: * Connected to 127.0.0.1 (127.0.0.1) port 8990 (#0)
RUN: > GET /verifiedserver HTTP/1.1
RUN: > User-Agent: curl/7.19.0-CVS (i686-pc-linux-gnu)
libcurl/7.19.0-CVS OpenSSL/0.9.8g zlib/1.2.3.3 libidn/0.6.5
libssh2/0.18
RUN: > Host: 127.0.0.1:8990
RUN: > Accept: */*
RUN: >
RUN: < HTTP/1.1 200 OK
RUN: < Content-Length: 17
RUN: <
RUN: { [data not shown]
RUN: * Connection #0 to host 127.0.0.1 left intact
RUN: * Closing connection #0
RUN: HTTP server is now running PID 30997
* pid http => 30997 30997
test 001...[HTTP GET]
../libtool --mode=execute /usr/bin/valgrind --tool=memcheck
--leak-check=yes --num-callers=16 --log-file=log/valgrind1 ../src/curl
--output log/curl1.out --include --verbose --trace-time
http://127.0.0.1:8990/1 >>log/stdout1 2>>log/stderr1
sh: line 1: 31014 Segmentation fault ../libtool --mode=execute
/usr/bin/valgrind --tool=memcheck --leak-check=yes --num-callers=16
--log-file=log/valgrind1 ../src/curl --output log/curl1.out --include
--verbose --trace-time http://127.0.0.1:8990/1 >>log/stdout1
2>>log/stderr1
core dumped

(I commented out the 'unlink core' in the script and caught the core file)
 file core
core: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV),
SVR4-style, from 'lt-curl'
$ gdb ../src/.libs/lt-curl core
GNU gdb 6.5-debian
..
Program terminated with signal 11, Segmentation fault.
#0 Curl_freeaddrinfo (ai=0xb7f89084) at hostip.c:565
565 free(ai->ai_canonname);
(gdb) where
#0 Curl_freeaddrinfo (ai=0xb7f89084) at hostip.c:565
#1 0xb7f89084 in freednsentry (freethis=0xb7faab50) at hostip.c:516
#2 0xb7faab50 in hash_element_dtor (user=0x8072100,
element=0x807b9c8) at hash.c:45
#3 0xb7faa92c in Curl_llist_remove (list=0x807b120, e=0x807b9f0,
user=0x8072100) at llist.c:116
#4 0xb7faa9af in Curl_llist_destroy (list=0x807b120, user=0x8072100)
at llist.c:128
#5 0xb7fab1a6 in Curl_hash_clean (h=0x8072100) at hash.c:235
#6 0xb7fab2e2 in Curl_hash_destroy (h=0x8072100) at hash.c:272
#7 0xb7f97bcd in Curl_close (data=0xb7fa87e9) at url.c:471
#8 0xb7fa87e9 in curl_easy_cleanup (curl=0x804c0c1) at easy.c:545
#9 0x0804c0c1 in operate (config=0xfbf990b7, argc=134723952,
argv=0x807b9a8) at main.c:5038
#10 0x0804a462 in main (argc=10, argv=0xbf81b2a4) at main.c:5098
(gdb) print ai
$1 = (const Curl_addrinfo *) 0xb7f89084
(gdb) print *ai
$2 = {ai_flags = -3374197, ai_family = -11141121, ai_socktype =
147096336, ai_protocol = -1866244773, ai_addrlen = 2819460435,
  ai_canonname = 0x8dffffff <Address 0x8dffffff out of bounds>,
ai_addr = 0xffffe815, ai_next = 0xe8ff}
(gdb)

This appears to have been going on since 10th of July (the same build
at the 9th looks OK).
I've been doing some checking on this, and I suspect the problem is
not at that particular point - if I add printfs here and there, or
compile with different optimizations, the error moves around. So it
looks like there's something getting overwritten somewhere.

-Tor
Received on 2008-08-29