From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124398 invoked by alias); 28 Mar 2019 04:59:26 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 124382 invoked by uid 89); 28 Mar 2019 04:59:26 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KAM_SHORT,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=mis, sk:xry111, xry111mengyan1223wang, U*xry111 X-HELO: mengyan1223.wang Received: from mengyan1223.wang (HELO mengyan1223.wang) (89.208.246.23) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 28 Mar 2019 04:59:23 +0000 Received: from xry111-laptop (unknown [IPv6:2408:8270:a5f:1170:4eed:4d65:f8bb:cd0a]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: xry111@mengyan1223.wang) by mengyan1223.wang (Postfix) with ESMTPSA id 298C765FEF; Thu, 28 Mar 2019 00:59:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mengyan1223.wang; s=mail; t=1553749161; bh=SNeqD8yfglecXJgQcvVcR/6xGmmzEcAHU8cxJoPARMU=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=0elPKrALyuTeaP/kvo8g+ekiILRzRu8u/FjETC+5l5zR+5sRfySb00fYti7HItTj9 WQsdQVfhONbsFAWoA8SuM/owvq5jqzOEmHWp5radg+kP3mmi8k9pPqL3rGjAsDwwuC XsrbN3p+sCbsWMjey/l0w+sw/f93Vo6CJzqkUEZfEIpTB2vYeME3EOBk4AVSl+sCFZ hqqDpoCmW9OosQviTgy3lz2YbLVPAbmoKGV6H7fCmOZi9x8IRjeofM42Ak0hJWfUG0 XsrWT02o28yLX8cuLuNijeU732dGIhTJNDdXXwOr6/ExI3iERNeJYZqdFerHSIxM2u LQv+Fo2kZBNyw== Message-ID: Subject: Re: Recursive SIGSEGV question From: Xi Ruoyao To: Jonny Grant Cc: Jonathan Wakely , Florian Weimer , Andrew Haley , gcc-help Date: Thu, 28 Mar 2019 08:26:00 -0000 In-Reply-To: <490f5b68-a9a9-943e-6485-28c0fd51835d@jguk.org> References: <1255ee27-882f-ab4e-ea45-ba6f35791b45@jguk.org> <877ecuikq9.fsf@mid.deneb.enyo.de> <835d09ce-752a-c0f7-e5cf-210e855df2ab@jguk.org> <87ef6vkq8a.fsf@mid.deneb.enyo.de> <95ff2a72-47fb-5cc3-5852-08517e3ce76e@redhat.com> <87bm1yho61.fsf@mid.deneb.enyo.de> <490f5b68-a9a9-943e-6485-28c0fd51835d@jguk.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.0 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00201.txt.bz2 On 2019-03-27 23:47 +0000, Jonny Grant wrote: > > On 27/03/2019 21:34, Jonathan Wakely wrote: > > On Wed, 27 Mar 2019 at 21:27, Jonny Grant wrote: > > > Hi! > > > > > > Thank you for your reply and input. > > > > > > Maybe GCC's "libbacktrace" module could be used? > > > > > > I was wondering if -fsanitize=address would output a backtrace for the > > > C++ exception, but it doesn't seem to. Also it actually prevents the > > > core being dumped - that's probably not intended? > > > > > > Compile without Sanitizer, and it does dump the core to a file at least! > > > > > > $ export UBSAN_OPTIONS=print_stacktrace=1 > > > > This is a UBsan option. > > > > > // g++-8 -fsanitize=address -Wall -o exception exception.cpp > > > > But you're not using UBsan. > > > > > #include > > > int main() > > > { > > > std::vector v; > > > return v.at(0); > > > } > > > > > > > > > $ ./exception > > > terminate called after throwing an instance of 'std::out_of_range' > > > what(): vector::_M_range_check: __n (which is 0) >= this->size() > > > (which is 0) > > > Aborted > > > > There's no undefined behaviour or memory corruption here, so it's not > > surprising that UBsan and Asan don't print anything. C++ exception is a well-defined language feature. There are even guys (mis)using it in cases we normally use "if (...) {...}" > Ok I see, thank you for pointing this out. > > I did wonder, as -fsanitize=address seems to inhibit the core dump that > is otherwise created by the abort() that appears to be called - is that > a known issue? > > $ g++-8 -Wall -o exception exception.cpp > jonny@asus:~/code/crash$ ./exception > terminate called after throwing an instance of 'std::out_of_range' > what(): vector::_M_range_check: __n (which is 0) >= this->size() > (which is 0) > Aborted (core dumped) > $ > > Usually I just load the core dump into GDB to take a look at it. It seems so. I don't know if this is a intentional feature or an oversight. > > If you want a stack trace for exceptions that terminate the process > > then you could install a custom terminate handler which does that. > > Libstdc++'s default terminate handler just prints the message above, > > which includes the type of the exception and if it's a type derived > > from std::exception, the what() string stored in it. > > Yes, I'd love to have a stack trace for exceptions that terminate the > process. Do you know a simple example you can refer me to? I've looked > and there are people using boost::stacktrace::stacktrace() but I'd > rather not link to boost as a dependency. > > It would be great if there was a glibc option to do this, or GCC could > insert it. > Otherwise we each need to insert our own stack tracers... > > Found this: > https://www.gnu.org/software/libc/manual/html_node/Backtraces.html > > I added this (attached) to a C++ exception handler, but there's no file > and line numbers. Other examples resort to calling addr2line! Seems a > bit over the top for us each to code our own stack tracer... Or reading > symbols etc. Am I asking too much for a general print_backtrace() in > libc or elsewhere ? Providing backtrace with file:line requires to parse debug info. glibc libSegFault.so just record a stack bracktrace w/o line numbers. The shell wrapper catchsegv convert addresses into line numbers calling addr2line. If you don't want to call addr2line (or other tools) you'll need DWARF parser in the executable. Why should we bloat the executable with a lot of code which should be in (and has been in) a debugger? For a comparision, Go provides a good stack backtrace at panics. But how big a Go executable is? A "hello world" takes 1997502 bytes! While a C++ one compiled by G++ is 22088 bytes (with debug info). If you need a backtrace in debug, just call a debugger. If you think you'll need it in _release_, I believe the right thing to do is catching the exceptions (or handle the signals) you care and log them into a log file or a syslog facility. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University