dejagnu-commit
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Dejagnu-commit] [SCM] DejaGNU branch, master, updated. post-if-stmt-bra


From: Ben Elliston
Subject: [Dejagnu-commit] [SCM] DejaGNU branch, master, updated. post-if-stmt-braces-159-ge7d7a3e
Date: Wed, 29 Jul 2015 22:15:14 +0000

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "DejaGNU".

The branch, master has been updated
       via  e7d7a3e0b0cda9194c192e979f4ecc8dcfb010b3 (commit)
      from  dfeb344621c7a607be33409acf3702961dee4866 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit e7d7a3e0b0cda9194c192e979f4ecc8dcfb010b3
Author: Pedro Alves <address@hidden>
Date:   Thu Jul 30 07:47:52 2015 +1000

        * lib/remote.exp (close_wait_program): New procedure.
        (local_exec, standard_close): Use it.
    
    The code that tries to make sure that a process dies in
    lib/remote.exp:remote_close can kill the wrong process due to PID-reuse
    races.  The GDB buildbots show frequent misterious FAILs that turns out
    are caused by this.  The problem is this bit here:
    
       exec sh -c "exec > /dev/null 2>&1 && (kill -2 $pgid || kill -2 $pid)
          && sleep 5 && (kill $pgid || kill $pid) && sleep 5 && (kill -9 $pgid 
|| kill -9 $pid) &"
       ...
       catch "wait -i $shell_id"
    
    When this procedure is called to close the GDB process, GDB exits
    promptly, but that whole cascade of kills carries on in the background,
    thus potentially killing the unfortunate process that manages to be
    spawned by one of the next tests and happens to reuse that $pid. [1]
    
    So to fix this, kill that no-longer-needed pipeline as soon as "wait"
    returns.  There are two places in the DejaGnu with a similar pipeline,
    so move that to a shared procedure.
    
    [1] GDB'S testsuite spawns thousands of GDB instances and even more
    inferior processes, and of those inferiors, some spawn thousands of
    short lived threads in quick succession.  Since threads and processes
    share the number space in Linux, all that causes PID recycling
    frequently.  In addition, GDB's testsuite has a parallel test mode that
    runs several tests/DejaGnu instances at the same time, further widening
    the race window.
    
    Signed-off-by: Ben Elliston <address@hidden>

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog      |    5 +++
 lib/remote.exp |   84 +++++++++++++++++++++++++++++++++++++++++--------------
 2 files changed, 67 insertions(+), 22 deletions(-)


hooks/post-receive
-- 
DejaGNU



reply via email to

[Prev in Thread] Current Thread [Next in Thread]