From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5024 invoked by alias); 12 May 2010 18:08:56 -0000 Received: (qmail 5015 invoked by uid 22791); 12 May 2010 18:08:56 -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 smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 12 May 2010 18:08:51 +0000 Received: from mailhost3.vmware.com (mailhost3.vmware.com [10.16.27.45]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 1BCE2121BC for ; Wed, 12 May 2010 11:08:49 -0700 (PDT) Received: from msnyder-server.eng.vmware.com (promd-2s-dhcp138.eng.vmware.com [10.20.124.138]) by mailhost3.vmware.com (Postfix) with ESMTP id 0DBACCD939 for ; Wed, 12 May 2010 11:08:49 -0700 (PDT) Message-ID: <4BEAEEB0.5040202@vmware.com> Date: Wed, 12 May 2010 18:08:00 -0000 From: Michael Snyder User-Agent: Thunderbird 2.0.0.22 (X11/20090609) MIME-Version: 1.0 To: "gdb-patches@sourceware.org" Subject: [RFC] persistence of schedlock mode Content-Type: multipart/mixed; boundary="------------000406090201040303000005" X-IsSubscribed: yes 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/msg00260.txt.bz2 This is a multi-part message in MIME format. --------------000406090201040303000005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 487 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? --------------000406090201040303000005 Content-Type: text/plain; name="schedlock.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="schedlock.txt" Content-length: 1236 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) --------------000406090201040303000005--