From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77384 invoked by alias); 7 Feb 2017 10:30:53 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 77372 invoked by uid 89); 7 Feb 2017 10:30:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=4.8 required=5.0 tests=BAYES_50,BODY_8BITS,GARBLED_BODY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=8:01, 8:=bf=c3, 8:7=c3, catches?= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 07 Feb 2017 10:30:50 +0000 Received: from smtp.corp.redhat.com (int-mx16.intmail.prod.int.phx2.redhat.com [10.5.11.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 53F1481247; Tue, 7 Feb 2017 10:30:50 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1AFA997CBA; Tue, 7 Feb 2017 10:30:48 +0000 (UTC) Subject: Re: Issue with Latest GDB on AIX with GCC-6.12 To: Nitish Kumar Mishra References: <21a21388-b1d9-816c-377e-d4e084cc399e@redhat.com> Cc: David Edelsohn , "gdb@sourceware.org" , Yao Qi From: Pedro Alves Message-ID: <331a72d9-050c-7cd7-adc2-78e5f1ed6f85@redhat.com> Date: Tue, 07 Feb 2017 10:30:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2017-02/txt/msg00002.txt.bz2 On 02/07/2017 08:05 AM, Nitish Kumar Mishra wrote: > Hi All ! > > As Pedro suggested to have some print statements in "catches" blocks > to identify the frame that can't be unwound, I did try that. > Most of the functions didn't have the try-catch except, > gdb_rl_callback_handler () > gdb_rl_callback_read_char_wrapper () > gdb_rl_callback_read_char_wrapper_noexcept (), > where I put the print statements but during execution none of these > print statements get executed. Actually, I suggested to _add_ more try/catch blocks. Taking the backtrace from your original post: > Breakpoint 3, _ZL19throw_exception_cxx13gdb_exception (exception=...) > at common/common-exceptions.c:289 > 289 common/common-exceptions.c: A file or directory in the path > name does not exist.. > (top-gdb) bt > #0 _ZL19throw_exception_cxx13gdb_exception (exception=...) at > common/common-exceptions.c:289 > #1 0x000000010005b848 in _Z15throw_exception13gdb_exception > (exception=...) at common/common-exceptions.c:317 > #2 0x000000010005ba3c in _ZL8throw_it13return_reason6errorsPKcPc > (reason=RETURN_ERROR, error=GENERIC_ERROR, > fmt=0x100817628 "The program is > not being run.", ap=0xfffffffffffee18 "\017ÿÿÿÿÿþX") at > common/common-exceptions.c:373 > #3 0x000000010005babc in _Z12throw_verror6errorsPKcPc (error=GENERIC_ERROR, > fmt=0x100817628 "The program is > not being run.", ap=0xfffffffffffee18 "\017ÿÿÿÿÿþX") at > common/common-exceptions.c:379 > During symbol reading, Method has bad physname > _ZNKSt17integral_constantIbLb0EEcvbEv > . > During symbol reading, struct/union type gets multiply defined: struct > initializer_list. > #4 0x000000010005f07c in _Z6verrorPKcPc (string=0x100817628 > "The program is not being run.", > args=0xfffffffffffee18 "\017ÿÿÿÿÿþX") at utils.c:475 > #5 0x0000000100085af0 in _Z5errorPKcz (fmt=0x100817628 > "The program is not being run.") at > common/errors.c:43 > #6 0x00000001001e1938 in _ZL12kill_commandPci (arg=0x0, from_tty=1) > at infcmd.c:2578 > #7 0x0000000100134200 in _ZL8do_cfuncP16cmd_list_elementPci > (c=0x1102442d0, args=0x0, from_tty=1) at cli/cli-decode.c:105 > #8 0x0000000100139464 in _Z8cmd_funcP16cmd_list_elementPci > (cmd=0x1102442d0, args=0x0, from_tty=1) at cli/cli-decode.c:1913 > #9 0x00000001000aca90 in _Z15execute_commandPci (p=0x11018f234 "", > from_tty=1) at top.c:674 > #10 0x00000001000b4cb4 in _Z15command_handlerPc (command=0x11018f230 > "kill") at event-top.c:590 > #11 0x00000001000b5288 in _Z20command_line_handlerPc (rl=0x11018f610 > "") at event-top.c:780 > #12 0x00000001000b4004 in _ZL23gdb_rl_callback_handlerPc > (rl=0x11018f610 "") at event-top.c:213 We know the exception should be caught in frame #12. But somehow, the run time unwinder doesn't realize this, and calls std::terminate, meaning it can't find a matching catch for the thrown exception. This suggests that the unwinder can't unwind some frame from the set of frames #0 to frame #12. The suggestion was to _add_ try/catch blocks in some frames between #0 - #12, and do some printing in the added catch blocks. For example, wrap frame #6, i.e., the kill_command function, by renaming it to kill_command_org and add: static void kill_command (char *arg, int from_tty) { try { kill_command_org (arg, from_tty); } catch (...) { printf ("%s:%d: got here\n", __FILE__, __LINE__) throw; } } This will cut in half the potential problematic frames. Alternatively, someone could debug the unwinder itself (libgcc?), which should also reveal why didn't the unwinder find that there's a "catch" in frame #12 in the original backtrace that catches the thrown exception. I'm assuming that we've run into a corner case, and that GDB has thrown other C++ exceptions that were caught successfully before we get to this problematic exception, during gdb startup. I.e., I don't recall whether I confirmed that a simple hello-word that does try{throw 1;}/catch(...){} manages to catch the exception correctly. If it doesn't then there's some fundamental problem with C++ exceptions in this compiler build. Speaking of compilers, we know that building gdb with gcc 4.8.5 doesn't run into this. Do we know that changed? Did, for example, AIX switch from sjlj to dwarf-based exceptions between gcc 4.8.5 and 6.1? Might also be useful to try to build gdb with current gcc trunk / gcc 7. Thanks, Pedro Alves