From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 3A2B23858014 for ; Fri, 11 Feb 2022 11:17:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3A2B23858014 Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-471-U7dTkbSNP_a7ZHW0c-tZPQ-1; Fri, 11 Feb 2022 06:16:58 -0500 X-MC-Unique: U7dTkbSNP_a7ZHW0c-tZPQ-1 Received: by mail-wm1-f70.google.com with SMTP id l20-20020a05600c1d1400b0035153bf34c3so5764558wms.2 for ; Fri, 11 Feb 2022 03:16:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version; bh=k+oDGKcT5RB6b4qgqV9FfQkN3MPgUmOFqDogC3A7IvM=; b=CmLdCkE5G+KSl3HxowN9sQJsPZo72NkOWz56VR81JHwCB72fRJl0qSjDmR28vw3vOv g1tXYwmsf4pYCveDMyawGGslEn6csvmaDrhiyE8D4ZjfiV1WSW/x2N8D9WtVIc96SurW 5Dh6wYNIJHvGRtL6sOwxDEQh3hlRFiZVrQcBDSLixNzE3iUirbsS6bOEDsw4Q/vidvHV JPwNwAEMWA/6FyKwTs6dq0y6vwU1WtxTHY21oNBbBXsC90+MOidf6R5iyV+j8JGJrRAC cB5L27ys40VwCVqvYRxgVFXQfnXCkQgo5GQzcht/yn6xTVLYcRhtXayKax1rZsKh9ClF BnBw== X-Gm-Message-State: AOAM532lxJ126o20HeLMASD9RzI4UlZ3oX0ooXJqgNrGODNyBrvWDzsp lQFHgo7UkcglDnHQmMB3bwHY4YCJwtfSNiNEi5eUSWnyL7XsSqrvv5K6K7RU+nYcLnz/Hprg4/k tL4mY5SIQ1pw= X-Received: by 2002:a05:600c:2551:: with SMTP id e17mr1068949wma.128.1644578216852; Fri, 11 Feb 2022 03:16:56 -0800 (PST) X-Google-Smtp-Source: ABdhPJyH9KPOcu9x0FILYJr7b4Ab4KRLY3GHs5P8VrygYgjioCyuUbrHPfOIMKRGrjzVz7n3ZY6HtA== X-Received: by 2002:a05:600c:2551:: with SMTP id e17mr1068926wma.128.1644578216604; Fri, 11 Feb 2022 03:16:56 -0800 (PST) Received: from localhost (host86-134-151-224.range86-134.btcentralplus.com. [86.134.151.224]) by smtp.gmail.com with ESMTPSA id a13sm3651661wmq.28.2022.02.11.03.16.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Feb 2022 03:16:56 -0800 (PST) From: Andrew Burgess To: Edgar Mobile , "gdb\@sourceware.org" Subject: Re: Have GDB exit on SIGABRT In-Reply-To: References: Date: Fri, 11 Feb 2022 11:16:55 +0000 Message-ID: <871r09fyag.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2022 11:17:03 -0000 Edgar Mobile via Gdb writes: > I want to start a gdb session for a process within a test environment > that executes some commands via script. The test environment is > configured so that it sends a SIGABRT after ten minutes which was > enough to end the original process. With a GDB session however it will > cause gdb to halt there which means the overall process never stops. My assumption here is that the SIGABRT is being sent to the inferior (the thing you're debugging), not GDB. If the SIGABRT is sent direct to GDB then that would kill GDB, which would cause the inferior to exit too (assuming the inferior is started under GDB, and you're not attaching. > Is it possible to configure the setup so that GDB completely quits > when a SIGABRT arrives? I'd consider making use of `handle`[1], something like `handle SIGABRT pass print nostop` will mean that when the SIGABRT arrives GDB will pass the signal to the inferior, killing it. Now you might be able to queue up an exit, something like this worked for me: gdb -ex 'file ~/tmp/loop.x' -ex 'handle SIGABRT pass print nostop' -ex 'run' -ex 'quit' Where loop.x just runs forever. Then, when I send SIGABRT to loop.x the 'run' command finishes, and the 'quit' gets run, which quits GDB. You could also replace the 'quit' with the -batch command line flag[2], but that makes less sense if you're running the commands from a script I think. Finally, if your script is more involved, and you want more control for when to quit gdb, you could consider using the Python API. The events mechanism[3] would allow you to handle the inferior exiting, or you could drop the use of 'handle' completely, and catch the stop event, check if the stop is due to SIGABRT, and then quit GDB. Hope some of this helps, Thanks, Andrew [1] https://sourceware.org/gdb/onlinedocs/gdb/Signals.html#Signals [2] https://sourceware.org/gdb/onlinedocs/gdb/Mode-Options.html#Mode-Options [3] https://sourceware.org/gdb/onlinedocs/gdb/Events-In-Python.html#Events-In-Python