From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124325 invoked by alias); 29 Mar 2019 00:05:55 -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 124304 invoked by uid 89); 29 Mar 2019 00:05:55 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy= X-HELO: mail-wr1-f46.google.com Received: from mail-wr1-f46.google.com (HELO mail-wr1-f46.google.com) (209.85.221.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 29 Mar 2019 00:05:53 +0000 Received: by mail-wr1-f46.google.com with SMTP id w1so422368wrp.2 for ; Thu, 28 Mar 2019 17:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jguk-org.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=B2WGkHMRqs2cFHvMumFi8q/M6YAyVtX4fczrlbhZ/SA=; b=A6fBtBOxTbderKawJs8PSjjhWIaL0IIeRbndP3JlYr1wqLt9ibNtFrAhktPmOyON5T lHDB8PYmFVO2ZrsASv2MjYs4fEPDPtn5Ny5dZCFFqPNNGaMQB5M3rHGQ5D2A8uj/CJXZ Xa2qWOydcxTMyesoeQ6nELikipZYAVQ40XOqoFPVU2ncUkRNKzzeUs5vowKuyxW03lc/ 8MQbqCow4Xq2WaLQqkfuRXwjvgOmnA8hNbSTlVwyLpSdcGIdBxgNjcp490BfldNe5m34 Clpt93uGLIGQbqmQ4v/hXQh9zqJ7ZHAk4bPVACSgwtALtJroFKnPdr8t1xwV4zciaBhw 2tPg== Return-Path: Received: from [192.168.1.71] (251.98.189.80.dyn.plus.net. [80.189.98.251]) by smtp.gmail.com with ESMTPSA id e193sm1125707wmg.18.2019.03.28.17.05.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2019 17:05:49 -0700 (PDT) Subject: Re: Recursive SIGSEGV question To: Xi Ruoyao Cc: Jonathan Wakely , Florian Weimer , Andrew Haley , gcc-help 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> From: Jonny Grant Message-ID: <3f191a23-97c3-3f40-3760-8f41074901e0@jguk.org> Date: Fri, 29 Mar 2019 02:24:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------BDA40AE613A509FB31C41792" X-SW-Source: 2019-03/txt/msg00213.txt.bz2 This is a multi-part message in MIME format. --------------BDA40AE613A509FB31C41792 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-length: 5064 On 28/03/2019 04:59, Xi Ruoyao wrote: > 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. Hi! libSegFault.so seems like a big module! If it only records stack frames like the backtrace() and backtrace_symbols() functions get in around 10 lines of code. Maybe libSegFault does a lot more than it seems. I was using these functions https://www.gnu.org/software/libc/manual/html_node/Backtraces.html catchsegv doesn't show line numbers for me: backtrace: ./loop(+0x9ae)[0x55ee7f23e9ae] ./loop(+0xa03)[0x55ee7f23ea03] ./loop(+0xa03)[0x55ee7f23ea03] [repeats] This is the stack overflow testcase. Please find attached. The file does have the info: $ addr2line -e loop 0xa03 /home/jonny/code/crash/loop.cpp:7 (discriminator 4) > > 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). My little test exception file leaps up from 31K to 81K when compiled with backtrace() and backtrace_symbols() A lot of increase... Considering they are library functions I am surprised its 50K bigger. I've not attached that program, but can share if needed.. > 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. Sounds good! Yes, that sounds good. Jonny --------------BDA40AE613A509FB31C41792 Content-Type: text/x-c++src; name="loop.cpp" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="loop.cpp" Content-length: 175 // g++-8 -ggdb -g -O0 -o loop loop.cpp #include static void func(std::string f, int g) { func(f.c_str(), g); } int main() { func("a", 0); return 0; } --------------BDA40AE613A509FB31C41792--