[Bug gdb/11328] New: std::terminate isn't caught if one manually calls an inferior function that calls dlopen

[Bug gdb/11328] New: std::terminate isn't caught if one manually calls an inferior function that calls dlopen

[pedro at codesourcery dot com]

Below are a couple of contrived examples to show the problem.

Example 1, with dlopen call:

1:

 void function (void)
 {
   dlopen (SHLIB_NAME, RTLD_LAZY);
   std::terminate ();
 }

 int main()
 {
 }

(gdb) start
(gdb) call function ()
terminate called without an active exception

Program received signal SIGABRT, Aborted.
0x00007ffff70f44b5 in raise () from /lib/libc.so.6
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(function()) will be abandoned.
When the function is done executing, GDB will silently stop.
(gdb)


But if one removes the call to dlopen, the problem is gone.  Example 2
below shows that.

2:

 void function (void)
 {
   std::terminate ();
 }

 int main()
 {
 }

(gdb) start
(gdb) call function ()

Breakpoint 0, 0x00007ffff7992110 in std::terminate() () from /usr/lib/libstdc++.so.6
The program being debugged entered a std::terminate call, most likely
caused by an unhandled C++ exception.  GDB blocked this call in order
to prevent the program from being terminated, and has restored the
context to its original state before the call.
To change this behaviour use "set unwind-on-terminating-exception off".
Evaluation of the expression containing the function (function())
will be abandoned.
(gdb)

-- 
           Summary: std::terminate isn't caught if one manually calls an
                    inferior function that calls dlopen
           Product: gdb
           Version: 7.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
        AssignedTo: unassigned at sourceware dot org
        ReportedBy: pedro at codesourcery dot com
                CC: gdb-prs at sourceware dot org


http://sourceware.org/bugzilla/show_bug.cgi?id=11328

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug gdb/11328] std::terminate isn't caught if one manually calls an inferior function that calls dlopen

[pedro at codesourcery dot com]

------- Additional Comments From pedro at codesourcery dot com  2010-02-26 01:39 -------
That is, assuming GDB doesn't crash as shown in
<http://sourceware.org/ml/gdb-patches/2010-02/msg00625.html>


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1


http://sourceware.org/bugzilla/show_bug.cgi?id=11328

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug gdb/11328] std::terminate isn't caught if one manually calls an inferior function that calls dlopen

[pedro at codesourcery dot com]

------- Additional Comments From pedro at codesourcery dot com  2010-02-26 01:44 -------
The problem is that dlopen causes a breakpoint reset, and breakpoint
resetting deletes (and uninstalls from the target) the std::terminate
breakpoint, because this breakpoint is of bp_breakpoint type, and has
no `b->addr_string' set (being a momentary breakpoint).

      if (b->addr_string == NULL)
	{
	  /* Anything without a string can't be re-set. */
	  delete_breakpoint (b);
	  return 0;
	}


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11328

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug gdb/11328] std::terminate isn't caught if one manually calls an inferior function that calls dlopen

[tromey at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at sourceware dot|tromey at redhat dot com
                   |org                         |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|0000-00-00 00:00:00         |2010-03-16 20:38:32
               date|                            |


http://sourceware.org/bugzilla/show_bug.cgi?id=11328

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug gdb/11328] std::terminate isn't caught if one manually calls an inferior function that calls dlopen

[tromey at redhat dot com]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2010-03-25 20:49 -------
Subject: Bug 11328

CVSROOT:	/cvs/src
Module name:	src
Changes by:	tromey@sourceware.org	2010-03-25 20:48:53

Modified files:
	gdb            : ChangeLog breakpoint.c breakpoint.h infcall.c 
	                 infcmd.c inferior.h infrun.c 

Log message:
	PR gdb/11327, PR gdb/11328, PR breakpoints/11368:
	* infrun.c (handle_inferior_event): Change initialization of
	stop_stack_dummy.
	(handle_inferior_event): Change assignment to stop_stack_dummy.
	(normal_stop): Update use of stop_stack_dummy.
	(struct inferior_status) <stop_stack_dummy>: Change type.
	* inferior.h (stop_stack_dummy): Update.
	* infcmd.c (stop_stack_dummy): Change type.
	* infcall.c (cleanup_delete_std_terminate_breakpoint): New
	function.
	(call_function_by_hand): Call set_std_terminate_breakpoint.
	Rewrite std::terminate handling.
	* breakpoint.h (enum bptype) <bp_std_terminate,
	bp_std_terminate_master>: New.
	(enum stop_stack_kind): New.
	(struct bpstat_what) <call_dummy>: Change type.
	(set_std_terminate_breakpoint, delete_std_terminate_breakpoint):
	Declare.
	* breakpoint.c (create_std_terminate_master_breakpoint): New
	function.
	(update_breakpoints_after_exec): Handle bp_std_terminate_master.
	Call create_std_terminate_master_breakpoint.
	(print_it_typical): Handle new breakpoint kinds.
	(bpstat_stop_status): Handle bp_std_terminate_master.
	(bpstat_what): Correctly set call_dummy field.  Handle
	bp_std_terminate_master and bp_std_terminate.
	(print_one_breakpoint_location): Update.
	(allocate_bp_location): Update.
	(set_std_terminate_breakpoint): New function.
	(delete_std_terminate_breakpoint): Likewise.
	(create_thread_event_breakpoint): Update.
	(delete_command): Update.
	(breakpoint_re_set_one): Update.
	(breakpoint_re_set): Call create_std_terminate_master_breakpoint.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/ChangeLog.diff?cvsroot=src&r1=1.11530&r2=1.11531
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/breakpoint.c.diff?cvsroot=src&r1=1.467&r2=1.468
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/breakpoint.h.diff?cvsroot=src&r1=1.112&r2=1.113
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/infcall.c.diff?cvsroot=src&r1=1.128&r2=1.129
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/infcmd.c.diff?cvsroot=src&r1=1.262&r2=1.263
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/inferior.h.diff?cvsroot=src&r1=1.142&r2=1.143
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/infrun.c.diff?cvsroot=src&r1=1.434&r2=1.435


------- Additional Comments From tromey at redhat dot com  2010-03-25 20:53 -------
I checked in the fix.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|7.1                         |7.2


http://sourceware.org/bugzilla/show_bug.cgi?id=11328

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.