Re: Issue with Latest GDB on AIX with GCC-6.12

[Pedro Alves <palves@redhat.com>]

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 <type_print_raw_options+147320> "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 <type_print_raw_options+147320> "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
> <type_print_raw_options+147320> "The program is not being run.",
>     args=0xfffffffffffee18 "\017ÿÿÿÿÿþX") at utils.c:475
> #5  0x0000000100085af0 in _Z5errorPKcz (fmt=0x100817628
> <type_print_raw_options+147320> "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