From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) by sourceware.org (Postfix) with ESMTPS id 33E7A396E83D for ; Mon, 20 Feb 2023 10:36:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 33E7A396E83D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=jguk.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jguk.org Received: by mail-lf1-x135.google.com with SMTP id w27so1153658lfu.4 for ; Mon, 20 Feb 2023 02:36:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jguk.org; s=google; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=hoCtDMVH59n04N4qulCFalGJh2p10Lx7jtRQf+7HYLo=; b=JCytAttheIeLNhr+EEe2gYCk0HYEkHqNfLyllYRZ8wfLj23p6nAocyZkof6Qr0pvOI 86UIRkNM3Uc7loPoKjsd9cjA7+i7EJG0Aycbg1gnkaH2/Er/tpmJBum8xGy2GxPYAP9y bOQL53jtPXfiAg3sQrSZfIf9sUbM/J0ms5sOWIFJdJMtn6EnR215gUTVcZbFeO+fsJwF 3RReZ5bZ8lS9k8iZhJ8pf5RXnbYt7Q6h4bPNT/pvE/r9zBnNfHipjpi6aGiy09SPXA5Y Cf9Qy4QIpnP8zDC/O4zQfgmkOD5gfkkYYJlvcddh/VcnR0+vPexZPNDd/lqCB6wdoxHN PeXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=hoCtDMVH59n04N4qulCFalGJh2p10Lx7jtRQf+7HYLo=; b=bkYTPW3qyc+GpcOFn1uXdSTJBuqBJJRzjaHZNCgan38rXDxaoLZOzUpxS43PP9ZXby NYStlaZiDhUrEDIOF1XfFh4A8dGTrNleGxqP/g60PnzKAVI0SVTti5WOeMJTXdKeUv3E hRkML5hZpyz/5kmdFmIsQWzVfu0xh9LnS5cetHD9aM2gXHvUe46bQ+E66zuHJocJJCa2 0WDHTlvYNUFICvvZMj2+a4B14F5WfX1PRoHzU/VfeHKuWp5OhQjTSylmvryt9eWCtLCX icKU8gYbJvMmlWe2T4f5GRVawi2A8zscavX8xHjolSGnDG5Hjcziww4imlAgAeEt3eJ+ 5iXw== X-Gm-Message-State: AO0yUKXFex4SqNv8b2PaX4nlU3zWkKzAhyWruTMzJt34tkbF5NETw5Y8 qti31DDuQHlp1E2N+teTD6JtnRTGLDoIERLY X-Google-Smtp-Source: AK7set/6wgFblhMjHqN6kMGcr3fUunZsenbSbPRDijyUJXx1f4XyXqZucoO78LwZdo/pYWnunbwLYw== X-Received: by 2002:a05:600c:340a:b0:3d9:e5d3:bf with SMTP id y10-20020a05600c340a00b003d9e5d300bfmr5581901wmp.32.1676841715001; Sun, 19 Feb 2023 13:21:55 -0800 (PST) Received: from [192.168.0.12] (cpc87345-slou4-2-0-cust172.17-4.cable.virginm.net. [81.101.252.173]) by smtp.gmail.com with ESMTPSA id y25-20020a1c4b19000000b003dc4480df80sm8588702wma.34.2023.02.19.13.21.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Feb 2023 13:21:54 -0800 (PST) Message-ID: <04702b40-73b8-16d3-c80d-f39637d72221@jguk.org> Date: Sun, 19 Feb 2023 21:21:53 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: Recursive SIGSEGV question Content-Language: en-GB From: Jonny Grant 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> <3f191a23-97c3-3f40-3760-8f41074901e0@jguk.org> In-Reply-To: <3f191a23-97c3-3f40-3760-8f41074901e0@jguk.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 29/03/2019 00:05, Jonny Grant wrote: > > > 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 It's not pretty, but this wrapper catches NULL passed at compile time: std::string make_std_string(const char * const str) { // This line ensures: warning: dereference of NULL '0' [CWE-476] [-Wanalyzer-null-dereference] char b = *str; std::string s(str); s[0] = b; // copy it back to avoid unused variable warning return s; } int main() { const char * a = NULL; std::string result = make_std_string(a); std::cout << result; } note, there a PR in latest gcc for an issue, so need to use -Wno-analyzer-use-of-uninitialized-value to avoid std::string having an incorrect warning reported.