Re: RFC: fix bug with std::terminate handler

[Pedro Alves <pedro@codesourcery.com>]

On Thursday 25 February 2010 19:19:28, Tom Tromey wrote:
> >>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:
> 
> Tom> call_function_by_hand installs a momentary breakpoint on std::terminate,
> Tom> and then deletes it later.  However, this can cause a double deletion of
> Tom> the breakpoint.  In the bug, the called function is dlopen, which causes
> Tom> gdb to enter solib_add, which calls breakpoint_re_set, deleting the
> Tom> momentary breakpoint.
> 
> Pedro> Why doesn't stepping over "dlopen", with "(gdb) next" cause the
> Pedro> same problem with step-resume breakpoints?
> 
> The step-resume breakpoints have type bp_step_resume, which are handled
> specially by breakpoint_re_set_one.  The std::terminate breakpoint is
> just a plain bp_breakpoint.

Yes, that's the problem.

> I suppose I could add a new bptype, though that seems rather heavy for
> this.

No momentary breakpoint should have bp_breakpoint type.  All
that do will have the same problem.

I see infcmd.c:finish_backward is also broken in the same way
although finish_forward uses bp_finish.  In fact, it's exactly
this abuse of bp_breakpoint that let to the need of the
make_breakpoint_silent call there...

A `gdb_assert (type != bp_breakpoint)' in
set_momentary_breakpoint would be a Nice To Have.

There's also the option of making the breakpoint at
std::terminate be a real internal breakpoint, enabled/disabled
on need, a-la-E.g., enable_overlay_breakpoints or
set_longjmp_breakpoint.  The advantage is that if the
dlopen causes the first load of libstdc++ ever in
the binary (quite rare, but possible), the breakpoint
at std::terminate resolves itself magically and you
still catch a call to it.  This option requires adding a
breakpoint type as well.

> If you have a particular approach you think would be best, I would be
> happy to implement that.

Thanks.  Take your pick from the above.  I also though
of adding a flag to the breakpoint struct to tag it as
momentary/temporary, but it feels hackish and a bit
lazy given what I said above.  :-)  But I wouldn't say
no to such fix.

-- 
Pedro Alves