This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[RFC] persistence of schedlock mode
- From: Michael Snyder <msnyder at vmware dot com>
- To: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Wed, 12 May 2010 11:08:48 -0700
- Subject: [RFC] persistence of schedlock mode
Bug 11580 points out a problem related to persistence of the
scheduler locking mode. If you set the mode to "on" (which
means that only one thread can run), and then kill and restart
your program, the mode persists and your program may deadlock.
I don't think this is a problem for mode "step", and it could
be argued that mode "on" is "use at your own risk". However
I've been thinking about how to resolve it, and this simple
but intrusive patch is what I come up with.
Comments?
Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.438
diff -u -p -r1.438 infrun.c
--- infrun.c 6 May 2010 19:14:08 -0000 1.438
+++ infrun.c 12 May 2010 17:37:09 -0000
@@ -1416,6 +1416,18 @@ set_schedlock_func (char *args, int from
}
}
+/* reset_schedlock -- public */
+
+void
+reset_schedlock ()
+{
+ if (scheduler_mode == schedlock_on)
+ {
+ warning ("Resetting scheduler-lock mode to 'off'");
+ scheduler_mode = schedlock_off;
+ }
+}
+
/* True if execution commands resume all threads of all processes by
default; otherwise, resume only threads of the current inferior
process. */
Index: target.c
===================================================================
RCS file: /cvs/src/src/gdb/target.c,v
retrieving revision 1.250
diff -u -p -r1.250 target.c
--- target.c 6 May 2010 22:29:49 -0000 1.250
+++ target.c 12 May 2010 17:37:09 -0000
@@ -2231,6 +2231,10 @@ void
target_mourn_inferior (void)
{
struct target_ops *t;
+
+ /* Clear schedlock in infrun.c */
+ reset_schedlock ();
+
for (t = current_target.beneath; t != NULL; t = t->beneath)
{
if (t->to_mourn_inferior != NULL)