public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Philippe Waroquiers <philippe.waroquiers@skynet.be>
To: gdb-patches@sourceware.org
Subject: PING Re: [RFA] Fix tid-reuse sometimes blocks for a very long (infinite?) time.
Date: Sat, 24 Nov 2018 12:58:00 -0000	[thread overview]
Message-ID: <1543064313.13811.12.camel@skynet.be> (raw)
In-Reply-To: <20181104200048.2463-1-philippe.waroquiers@skynet.be>

Thanks
Philippe

On Sun, 2018-11-04 at 21:00 +0100, Philippe Waroquiers wrote:
> A failure that seems to cause a long/infinite time is the following:
> 
> For a not clear reason, tid-reuse.c spawner thread sometimes gets an error:
>      tid-reuse: /bd/home/philippe/gdb/git/build_moreaa/gdb/testsuite/../../../moreaa/gdb/testsuite/gdb.threads/tid-reuse.c:58: spawner_thread_func: Assertion `rc == 0' failed.
> 
> which causes a SIGABRT to be trapped by gdb, and tid-reuse does not reach the
> after_count breakpoint:
>   Thread 2 "tid-reuse" received signal SIGABRT, Aborted.
>   [Switching to Thread 0x7ffff7518700 (LWP 10368)]
>   __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
>   51	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
>   (gdb) FAIL: gdb.threads/tid-reuse.exp: continue to breakpoint: after_count
> 
> After that, tid-reuse.exp gets the value of reuse_time, but this one kept its
> initial value of -1 (as unsigned) :
>   print reuse_time
>   $1 = 4294967295
>   (gdb) PASS: gdb.threads/tid-reuse.exp: get reuse_time
> 
> tid-reuse then dies, and the .exp script continues (with some FAIL)
> till it executes:
>   set timeout [expr $reuse_time * 2]
> 
> leading to the error:
> 
>   (gdb) ERROR: integer value too large to represent as non-long integer
>       while executing
>   "expect {
>   -i exp8 -timeout 8589934590
>           -re ".*A problem internal to GDB has been detected" {
>               fail "$message (GDB internal error)"
>               gdb_intern..."
>       ("uplevel" body line 1)
>       invoked from within
>   "uplevel $body" ARITH IOVERFLOW {integer value too large to represent as non-long integer} integer value too large to represent as non-long integer
>   ERROR: GDB process no longer exists
> 
> and then everything blocks.
> This last 'GDB process no longer exists' is strange, as I still see the gdb
> when this all blocks, e.g.
> philippe 16058 31085  0 20:30 pts/15   00:00:00                         /bin/bash -c rootme=`pwd`; export rootme; srcdir=../../../binutils-gdb/gdb/testsuite ; export srcdir ; EXPECT=`if [
> philippe 16386 16058  0 20:30 pts/15   00:00:00                           expect -- /usr/share/dejagnu/runtest.exp --status GDB_PARALLEL=yes --outdir=outputs/gdb.threads/tid-reuse gdb.thre
> philippe 24848 16386  0 20:30 pts/20   00:00:00                             /bd/home/philippe/gdb/git/build_binutils-gdb/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory /bd/home/philip
> 
> This patch gives a default value of 60, so that if ever something wrong happens
> in tid-reuse, then the value retrieved by the .exp script stays in a reasonable
> range.
> Note that I could not reproduce this failure often enough to be sure that
> initializing to 60 ensures it does not block, but in any case, it should
> not harm.
> 
> gdb/testsuite/ChangeLog
> 
> 2018-11-04  Philippe Waroquiers  <philippe.waroquiers@skynet.be>
> 
> 	* gdb.threads/tid-reuse.c (REUSE_TIME_CAP): Declare as 60.
> 	(reuse_time): Initialize to REUSE_TIME_CAP.
> 	(main): Use REUSE_TIME_CAP instead of hardcoded 60.
> ---
>  gdb/testsuite/gdb.threads/tid-reuse.c | 11 +++++++----
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/gdb/testsuite/gdb.threads/tid-reuse.c b/gdb/testsuite/gdb.threads/tid-reuse.c
> index 1741325a5b..0cdd580441 100644
> --- a/gdb/testsuite/gdb.threads/tid-reuse.c
> +++ b/gdb/testsuite/gdb.threads/tid-reuse.c
> @@ -34,8 +34,11 @@ unsigned long thread_counter;
>     incremented, this is enough for the tid numbers to wrap around.  On
>     targets that randomize thread IDs, this is enough time to give each
>     number in the thread number space some chance of reuse.  It'll be
> -   capped to a lower value if we can't compute it.  */
> -unsigned int reuse_time = -1;
> +   capped to a lower value if we can't compute it.  REUSE_TIME_CAP
> +   is the max value, and the default value if ever the program
> +   has problem to compute it.  */
> +#define REUSE_TIME_CAP 60
> +unsigned int reuse_time = REUSE_TIME_CAP;
>  
>  void *
>  do_nothing_thread_func (void *arg)
> @@ -138,8 +141,8 @@ main (int argc, char *argv[])
>       pid_max=32768.  Going forward, as machines get faster, this will
>       need less time, unless pid_max is set to a very high number.  To
>       avoid unreasonably long test time, cap to an upper bound.  */
> -  if (reuse_time > 60)
> -    reuse_time = 60;
> +  if (reuse_time > REUSE_TIME_CAP)
> +    reuse_time = REUSE_TIME_CAP;
>    printf ("thread_counter=%lu, tid_max = %ld, reuse_time_raw=%u, reuse_time=%u\n",
>  	  thread_counter, tid_max, reuse_time_raw, reuse_time);
>    after_count ();

  reply	other threads:[~2018-11-24 12:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-04 20:01 Philippe Waroquiers
2018-11-24 12:58 ` Philippe Waroquiers [this message]
2018-12-02 15:59   ` PING^2 " Philippe Waroquiers
2018-12-04  2:56 ` Simon Marchi
2018-12-04 15:23 ` Pedro Alves
2018-12-04 23:11   ` Philippe Waroquiers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1543064313.13811.12.camel@skynet.be \
    --to=philippe.waroquiers@skynet.be \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).