Bugs item #3188836, was opened at 2011-02-22 05:12
Message generated for change (Comment added) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3188836&group_id=976
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: compile or build problem
Group: bad behaviour
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Greg Pratt (gprattnj)
Assigned to: Daniel Stenberg (bagder)
Summary: test 300 sends kill signal to wrong process
Initial Comment:
When running a "make check", test #300 will mistakenly try to kill a process with an impossibly large PID, which will result in an entire group of processes being killed. If I run this test on my system as the user who is logged in on the console, it will kill the Window Manager, causing my entire session to be terminated and logging me out. If I run this test as a different user, it will at least not kill my entire windowing system, so I can observe what is going on, but the incorrect signal target is still abnormally terminating the test and many other processes owned by that user.
I observed this problem in 7.21.4 (the current release version) and 7.21.3 (its predecessor), but did not observe the problem when building 7.21.2. It may have been there for some time, but simply hasn't manifested itself until now on my system.
With 7.21.4, the symptoms can be reproduced on my Mac OS X 10.5.8 system:
cd /usr/local/src/curl-7.21.4
./configure
make check
Normally, the tests should reach #300, either succeed or fail, and continue on to the next test.
Instead, this happens:
test 297...OK (292 out of 598, remaining: 02:08)
test 298...OK (293 out of 598, remaining: 02:07)
test 299...OK (294 out of 598, remaining: 02:06)
RUN: Unknown server on our https port: 8991 (28)
RUN: HTTPS server failed verification
runtests.pl received SIGTERM, exiting
make: *** [test] Terminated
Terminated
bash-3.2$ Somebody sent me a SIGTERM at ./runtests.pl line 300.
runtests.pl received SIGTERM, exiting
make[1]: *** [quiet-test] Error 2
If I run the test individually with the verbose flag, we see more of what is really happening:
bash-3.2$ cd /usr/local/src/curl-7.21.4_i386/tests
bash-3.2$ ./runtests.pl -v 300
********* System characteristics ********
* curl 7.21.4 (i386-apple-darwin9.8.0)
* libcurl/7.21.4 OpenSSL/1.0.0d zlib/1.2.5
* Features: IPv6 Largefile NTLM SSL libz
* Host: canis-major
* System: Darwin canis-major 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
* Server SSL: ON libcurl SSL: ON
* debug build: OFF track memory: OFF
* valgrind: OFF HTTP IPv6 ON
* FTP IPv6 ON Libtool lib: OFF
* Shared build: yes
* SSL library: OpenSSL
* Ports:
* HTTP/8990 FTP/8992 FTP2/8995 RTSP/9007 FTPS/8993 HTTPS/8991
* TFTP/8997 HTTP-IPv6/8994 RTSP-IPv6/9008 FTP-IPv6/8996
* GOPHER/9009 GOPHER-IPv6/9009
* SSH/8999 SOCKS/9000 POP3/9001 IMAP/9003 SMTP/9005
* POP3-IPv6/9002 IMAP-IPv6/9004 SMTP-IPv6/9006
*****************************************
startnew: perl -I. ./httpserver.pl --pidfile ".http_server.pid" --logfile "log/http_server.log" --ipv4 --port 8990 --srcdir "."
RUN: ../src/curl --max-time 13 --output log/http_verify.out --silent --verbose --globoff "http://127.0.0.1:8990/verifiedserver" 2>log/http_verify.log
RUN: HTTP server is now running PID 94366
* pid http => 94366 94366
startnew: perl -I. ./secureserver.pl --pidfile ".https_server.pid" --logfile "log/https_stunnel.log" --ipv4 --proto https --stunnel "/usr/local/bin/stunnel" --srcdir "." --connect 8990 --accept 8991
RUN: ../src/curl --max-time 13 --output log/https_verify.out --silent --verbose --globoff --insecure "https://127.0.0.1:8991/verifiedserver" 2>log/https_verify.log
RUN: curl command returned 28
RUN: * About to connect() to 127.0.0.1 port 8991 (#0)
RUN: * Trying 127.0.0.1... connected
RUN: * Connected to 127.0.0.1 (127.0.0.1) port 8991 (#0)
RUN: * successfully set certificate verify locations:
RUN: * CAfile: /usr/local/share/curl/curl-ca-bundle.crt
RUN: CApath: none
RUN: * SSLv3, TLS handshake, Client hello (1):
RUN: } [data not shown]
RUN: * SSL connection timeout
RUN: * Closing connection #0
RUN: Unknown server on our https port: 8991 (28)
RUN: HTTPS server failed verification
RUN: Process with pid 94366 signalled to die
RUN: Process with pid 94384 signalled to die
RUN: Process with pid 9438794366 signalled to die
runtests.pl received SIGTERM, exiting
Somebody sent me a SIGTERM at ./runtests.pl line 300.
It appears that something is concatenating the process ID numbers of "61889" and "61868" together without an intervening separator. If either the kernel or perl are interpreting this as a negative number, the man page for kill(2) describes a result which sounds much like the symptoms shown above:
"...For compatibility with System V, if the process number is
negative but not -1, the signal is sent to all processes whose
process group ID is equal to the absolute value of the process
number. This is a variant of killpg(2)."
This was built with the following options (the defaults with just a plain "configure" invocation)...
bash-3.2$ sh ../curl-config --libs --static-libs --features --protocols
-L/usr/local/lib -lcurl -L/usr/local/lib -lssl -lcrypto -lldap -lssl -lcrypto -lz
/usr/local/lib/libcurl.a -L/usr/local/lib -lssl -lcrypto -lldap -lssl -lcrypto -lz
SSL
IPv6
libz
NTLM
DICT
FILE
FTP
FTPS
GOPHER
HTTP
HTTPS
IMAP
IMAPS
LDAP
LDAPS
POP3
POP3S
RTSP
SMTP
SMTPS
TELNET
TFTP
This problem can be alleviated by adding a space $run{$server}, and not simply after it, when defining $pidlist in runtests.pl:stopserver():
*** tests/runtests.pl.orig 2011-02-10 16:24:15.000000000 -0500
--- tests/runtests.pl 2011-02-21 18:54:59.000000000 -0500
***************
*** 653,655 ****
if($run{$server}) {
! $pidlist .= "$run{$server} ";
$run{$server} = 0;
--- 653,655 ----
if($run{$server}) {
! $pidlist .= " $run{$server} ";
$run{$server} = 0;
runtests.pl handles multiple spaces gracefully (or at least ignores null elements created with split()), so this should be a harmless addition for cases where it isn't needed.
----------------------------------------------------------------------
Comment By: Daniel Stenberg (bagder)
Date: 2011-02-22 13:42
Message:
Thanks for the report, this problem is now fixed in the git repository.
To try it out, you either checkout/update your git clone:
http://curl.haxx.se/source.html
or you try tomorrow's daily snapshot: http://curl.haxx.se/snapshots/
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3188836&group_id=976
Received on 2011-02-22