cURL
Haxx ad
libcurl

curl's project page on SourceForge.net

Sponsors:
Haxx

cURL > Mailing List > Monthly Index > Single Mail

curl-tracker Archives

[ curl-Bugs-3188836 ] test 300 sends kill signal to wrong process

From: SourceForge.net <noreply_at_sourceforge.net>
Date: Tue, 22 Feb 2011 12:42:40 +0000

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

These mail archives are generated by hypermail.

donate! Page updated November 12, 2010.
web site info

File upload with ASP.NET