This is the mail archive of the gdb-cvs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

gdb and binutils branch master updated. 2bdd10b78e7e5b33c488af6fcb01255269e8a498


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 "gdb and binutils".

The branch, master has been updated
       via  2bdd10b78e7e5b33c488af6fcb01255269e8a498 (commit)
      from  72fde3dfe9a2367abc593684b9b4d2343d367d85 (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 -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=2bdd10b78e7e5b33c488af6fcb01255269e8a498

commit 2bdd10b78e7e5b33c488af6fcb01255269e8a498
Author: Maciej W. Rozycki <macro@codesourcery.com>
Date:   Tue Sep 9 16:06:15 2014 +0100

    GDB/testsuite: Extend the time gdbserver is waited for
    
    Gdbserver support code uses the global timeout value to determine when
    to stop waiting for a gdbserver process being started to respond before
    continuing anyway.  This timeout is usually as low as 10s and may not
    be enough in this context, for example on the first run where the
    filesystem cache is cold, even if it is elsewhere.
    
    E.g. I observe this reliably with gdbserver started the first time in
    QEMU running in the system emulation mode:
    
    (gdb) file .../gdb.base/advance
    Reading symbols from .../gdb.base/advance...done.
    (gdb) delete breakpoints
    (gdb) info breakpoints
    No breakpoints or watchpoints.
    (gdb) break main
    Breakpoint 1 at 0x87f8: file .../gdb.base/advance.c,
    line 41.
    (gdb) set remotetimeout 15
    (gdb) kill
    The program is not being run.
    (gdb)
    [...]
    .../bin/gdbserver --once :6014 advance
    target remote localhost:6014
    Remote debugging using localhost:6014
    Remote communication error.  Target disconnected.: Connection reset by peer.
    (gdb) continue
    The program is not being run.
    (gdb) Process advance created; pid = 999
    Listening on port 6014
    FAIL: gdb.base/advance.exp: Can't run to main
    
    -- notice how the test harness proceeded with the `target remote ...'
    command even though gdbserver hasn't completed its startup yet.  A
    while later when it's finally ready it's too late already.  I checked
    the timing here and it takes gdbserver roughly 25 seconds to start in
    this scenario.  Subsequent gdbserver starts in the same test run take
    less time and usually complete within 10 seconds although occasionally
    `target remote ...' precedes the corresponding `Listening on port...'
    message again.
    
    Therefore I have fixed this problem by setting an explicit timeout to
    120s on the expect call in question.  If this turns out too arbitrary
    sometime, then perhaps a separate `gdbserver_timeout' setting might be
    due.
    
    	* lib/gdbserver-support.exp (gdbserver_start): Set timeout to
    	120 on waiting for the TCP socket to open.

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

Summary of changes:
 gdb/testsuite/ChangeLog                 |    5 +++++
 gdb/testsuite/lib/gdbserver-support.exp |    1 +
 2 files changed, 6 insertions(+), 0 deletions(-)


hooks/post-receive
-- 
gdb and binutils


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]