From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <yuri@rawbw.com>
Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42])
 by sourceware.org (Postfix) with ESMTP id 882F53858D35
 for <gdb@sourceware.org>; Fri,  5 Nov 2021 17:21:51 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 882F53858D35
Received: from [192.168.5.3] (c-73-189-35-76.hsd1.ca.comcast.net
 [73.189.35.76]) (authenticated bits=0)
 by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id 1A5HLojC059037
 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO)
 for <gdb@sourceware.org>; Fri, 5 Nov 2021 10:21:50 -0700 (PDT)
 (envelope-from yuri@rawbw.com)
X-Authentication-Warning: shell1.rawbw.com: Host
 c-73-189-35-76.hsd1.ca.comcast.net [73.189.35.76] claimed to be [192.168.5.3]
Message-ID: <6e2fce20-199a-c986-1128-d5e634f05ba0@rawbw.com>
Date: Fri, 5 Nov 2021 10:21:49 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.2.1
To: gdb@sourceware.org
Content-Language: en-US
From: Yuri <yuri@rawbw.com>
Subject: Is it possible to make gdb stop on actual failure, and not inside of
 signal or inside of assert function?
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
 SPF_HELO_NONE, SPF_PASS autolearn=ham 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 <gdb.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/gdb>,
 <mailto:gdb-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/gdb>,
 <mailto:gdb-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Nov 2021 17:21:53 -0000

I start gdb from the signal handler of the debugged process.

When SEGV happens the signal handler starts 'gdb -p $PPID' using the 
'system' function.

gdb stops inside of the signal handler, inside of the system call, in 
_wait4().

This is 7 levels below the SEGV location.


Is there a way to make gdb skip signal handler and stop at the actual 
problem location,

which is the line that caused SEGV in my case?


gdb-11.1

FreeBSD 13


Thank you,

Yuri