From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22855 invoked by alias); 12 May 2010 19:25:21 -0000 Received: (qmail 22840 invoked by uid 22791); 12 May 2010 19:25:21 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO glazunov.sibelius.xs4all.nl) (83.163.83.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 12 May 2010 19:25:15 +0000 Received: from glazunov.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by glazunov.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id o4CJPB4s005996; Wed, 12 May 2010 21:25:11 +0200 (CEST) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id o4CJP9uR007227; Wed, 12 May 2010 21:25:09 +0200 (CEST) Date: Wed, 12 May 2010 19:49:00 -0000 Message-Id: <201005121925.o4CJP9uR007227@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: msnyder@vmware.com CC: gdb-patches@sourceware.org In-reply-to: <4BEAEEB0.5040202@vmware.com> (message from Michael Snyder on Wed, 12 May 2010 11:08:48 -0700) Subject: Re: [RFC] persistence of schedlock mode References: <4BEAEEB0.5040202@vmware.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-05/txt/msg00264.txt.bz2 > Date: Wed, 12 May 2010 11:08:48 -0700 > From: Michael Snyder > > 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? Ah, that's clever. The user will be notified, but doesn't have to answer an additional question. > 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)