From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10331 invoked by alias); 18 Jan 2013 15:01:55 -0000 Received: (qmail 10321 invoked by uid 22791); 18 Jan 2013 15:01:54 -0000 X-SWARE-Spam-Status: No, hits=-6.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_EG,TW_GJ X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 18 Jan 2013 15:01:41 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r0IF1VZr010576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Jan 2013 10:01:32 -0500 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r0IF1QEA023205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 18 Jan 2013 10:01:28 -0500 From: Tom Tromey To: Pedro Alves Cc: Pierre Muller , gdb-patches@sourceware.org Subject: Re: catch SIGSEGV in the demangler References: <87fw23o70u.fsf@fleche.redhat.com> <19236.9665638127$1358374641@news.gmane.org> <87622vd2vd.fsf@fleche.redhat.com> <50F93081.1090905@redhat.com> Date: Fri, 18 Jan 2013 15:01:00 -0000 In-Reply-To: <50F93081.1090905@redhat.com> (Pedro Alves's message of "Fri, 18 Jan 2013 11:22:41 +0000") Message-ID: <87pq12a62h.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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 X-SW-Source: 2013-01/txt/msg00428.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: Pedro> SIGSEGV being a synchronous signal, this makes it so that the Pedro> original instruction that triggered the segv is reexecuted, and Pedro> the SIGSEGV is raised again. The difference is that this way our Pedro> handler is transparent -- the segv's siginfo will be more rich, Pedro> including a si_addr that points at the address that caused the Pedro> fault, (si_code will still show it was a userspace generated Pedro> signal), and "handle_segv" will not appear in the backtrace. Did Pedro> you try that and decided against? I didn't try, because the C standard says this is undefined behavior: If and when the function returns, if the value of sig is SIGFPE, SIGILL, SIGSEGV, or any other implementation-defined value corresponding to a computational exception, the behavior is undefined; otherwise the program will resume execution at the point it was interrupted. I couldn't find anything in POSIX suggesting otherwise. It seems to me that the failing spot will still be in the backtrace. So, the damage isn't so severe: (gdb) bt #0 0x0000003be3036540 in __sigprocmask (how=2, set=0x2f32850, oset=0x0) at ../sysdeps/unix/sysv/linux/ia64/sigprocmask.c:43 #1 0x0000003be303610b in __libc_siglongjmp (env=0x2f32808, val=-1) at longjmp.c:36 #2 0x0000003be3c0e179 in longjmp (env=, val=) at ../nptl/sysdeps/pthread/pt-longjmp.c:27 #3 0x0000000000722e48 in throw_exception (exception=...) at ../../archer/gdb/exceptions.c:234 #4 0x0000000000802a33 in handle_segv (sig=11) at ../../archer/gdb/safe-demangle.c:49 #5 #6 0x0000003be30e87c8 in __GI___poll (fds=0x2e2cff0, nfds=3, timeout=) at ../sysdeps/unix/sysv/linux/poll.c:83 #7 0x000000000072d1be in gdb_wait_for_event (block=1) at ../../archer/gdb/event-loop.c:863 Well, ok, the stack trace is weird, since in this scenario we aren't actually calling longjmp. I'm not sure what is going on there. If returning actually works everywhere, I am fine with doing that. Tom