From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32695 invoked by alias); 1 Oct 2014 23:51:12 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 32686 invoked by uid 89); 1 Oct 2014 23:51:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 01 Oct 2014 23:51:10 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s91Np8QJ003940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 1 Oct 2014 19:51:08 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s91Np6sc025738; Wed, 1 Oct 2014 19:51:07 -0400 Message-ID: <542C936A.60507@redhat.com> Date: Wed, 01 Oct 2014 23:51:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Doug Evans , gdb-patches@sourceware.org Subject: Re: [PATCH] Don't run forever in gdb.base/structs.c References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-10/txt/msg00023.txt.bz2 On 10/01/2014 10:02 PM, Doug Evans wrote: > If gdb crashes during testing tests may be left to free-run, eating cpu. > > This patch fixes one of the more egregious cases since several versions > of the program are built. > > I've got patches to fix others. > Just seeing if folks want to comment on this first. > > IWBN to have the harness itself cleanup, and I think there's something > we can do there, but that's not always robust either, and I think > multiple levels of robustness would be useful. Agreed. > Since this testcase is an egregious one, and since this patch simple, > I'm starting with this. Looks fine with me. We already do something like this in many tests even. E.g., of the top of my head: $ grep -rn "Don't run forever. Run just short of it :)" * gdb.base/watch_thread_num.c:55: /* Don't run forever. Run just short of it :) */ gdb.mi/nsintrall.c:55: /* Don't run forever. Run just short of it :) */ gdb.mi/nsmoribund.c:35: /* Don't run forever. Run just short of it :) */ gdb.threads/pending-step.c:54: /* Don't run forever. Run just short of it :) */ gdb.threads/watchthreads.c:71: /* Don't run forever. Run just short of it :) */ gdb.threads/threadapply.c:72: /* Don't run forever. Run just short of it :) */ gdb.threads/thread-specific.c:42: /* Don't run forever. Run just short of it :) */ gdb.threads/thread-specific.c:56: /* Don't run forever. Run just short of it :) */ gdb.threads/schedlock.c:55: /* Don't run forever. Run just short of it :) */ In a few other tests, we use "alarm()", though IMO it's best to avoid that if possible, to expose the test on as much targets as possible. E.g., alarm() IIRC isn't available on mingw unless you specify __USE_MINGW_ALARM. Bare metal targets may have trouble with it too, etc. Thanks, Pedro Alves