From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1282 invoked by alias); 5 Oct 2005 18:41:25 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 1261 invoked by uid 22791); 5 Oct 2005 18:41:23 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 05 Oct 2005 18:41:23 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1ENECf-0002l4-64; Wed, 05 Oct 2005 14:41:21 -0400 Date: Wed, 05 Oct 2005 18:41:00 -0000 From: Daniel Jacobowitz To: David Lecomber Cc: gdb Subject: Re: ptrace PEEKTEXT IO error?! Message-ID: <20051005184121.GA10564@nevyn.them.org> Mail-Followup-To: David Lecomber , gdb References: <1128531841.21837.96.camel@delmo.priv.wark.uk.streamline-computing.com> <20051005171106.GA7835@nevyn.them.org> <1128536411.21837.123.camel@delmo.priv.wark.uk.streamline-computing.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1128536411.21837.123.camel@delmo.priv.wark.uk.streamline-computing.com> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-10/txt/msg00014.txt.bz2 On Wed, Oct 05, 2005 at 07:20:11PM +0100, David Lecomber wrote: > On Wed, 2005-10-05 at 13:11 -0400, Daniel Jacobowitz wrote: > > On Wed, Oct 05, 2005 at 06:04:00PM +0100, David Lecomber wrote: > > > Dear all, > > > > > > I have a multithreaded code which is misbehaving in GDB (verified on > > > latest CVS). After threads are created, the target suddenly seems to > > > become unwriteable, and even unreadable in some bits. > > > > This usually means the thread is not stopped. Failing that, check with > > your kernel. > > 'ps' says the processes is stopped - so I guess that makes it a kernel > woe. > > I've knocked up a ptrace test code, and it also shows the same behaviour > independently of GDB. > > It seems ok at reading memory from addresses on the heap and stack -- > but it barfs at reading memory from the text segment. Is there > something that the user code (one of the libraries called by my > program) could do to prevent access to memory by a ptracing program? No, this is most likely a kernel bug. This is mapped code, right, not some mmaped device file (which is not generally accessible by ptrace)? -- Daniel Jacobowitz CodeSourcery, LLC