From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22625 invoked by alias); 17 May 2010 08:11:49 -0000 Received: (qmail 22613 invoked by uid 22791); 17 May 2010 08:11:47 -0000 X-SWARE-Spam-Status: No, hits=-0.1 required=5.0 tests=AWL,BAYES_50,MSGID_MULTIPLE_AT X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.152) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 17 May 2010 08:11:41 +0000 Received: from baal.u-strasbg.fr (baal.u-strasbg.fr [IPv6:2001:660:2402::41]) by mailhost.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id o4H8BccM031734 for ; Mon, 17 May 2010 10:11:38 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from mailserver.u-strasbg.fr (ms1.u-strasbg.fr [IPv6:2001:660:2402:d::10]) by baal.u-strasbg.fr (8.14.0/jtpda-5.5pre1) with ESMTP id o4H8AMoT084673 for ; Mon, 17 May 2010 10:10:28 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from d620muller (gw-ics.u-strasbg.fr [130.79.210.225]) (user=mullerp mech=LOGIN) by mailserver.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id o4H89jpZ014834 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 17 May 2010 10:09:47 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) From: "Pierre Muller" To: References: <4BEAEEB0.5040202@vmware.com> In-Reply-To: <4BEAEEB0.5040202@vmware.com> Subject: RE: [RFC] persistence of schedlock mode Date: Mon, 17 May 2010 10:33:00 -0000 Message-ID: <000c01caf598$50754fe0$f15fefa0$@muller@ics-cnrs.unistra.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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/msg00338.txt.bz2 Did I miss some part of the discussion here? I really have the impression that this patch went in by error in a long series of patches=20 from Michael all labeled with '[ob]... white space' without the patch itself being approved on the main thread.=20 First reset_schedlock went in and generated a 'New ARI warning' Jan replied to it http://sourceware.org/ml/gdb-patches/2010-05/msg00320.html Then, another commit of the same series http://sourceware.org/ml/gdb-cvs/2010-05/msg00145.html added a call to reset_schedlock in infrun.c. as can be seen in http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/target.c.diff?cvsroot=3Dsr= c&r 1=3D1.250&r2=3D1.251 This lead to a compilation error that Hui=20 tried to fix, and Joel added a second patch to cleanup. I have no opinion of the validity of the patch itself,=20 but the way it got into CVS leaves a strange impression to me. Pierre Muller Pascal language support maintainer for GDB > -----Message d'origine----- > De=A0: gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Michael Snyder > Envoy=E9=A0: Wednesday, May 12, 2010 8:09 PM > =C0=A0: gdb-patches@sourceware.org > Objet=A0: [RFC] persistence of schedlock mode >=20 > 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. >=20 > 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. >=20 > Comments?