NetBSD Problem Report #8564

Received: (qmail 26296 invoked from network); 6 Oct 1999 10:02:56 -0000
Message-Id: <199910061002.LAA16455@shark1.cambridge.arm.com>
Date: Wed, 6 Oct 1999 11:02:36 +0100 (BST)
From: Richard Earnshaw <rearnsha@cambridge.arm.com>
Reply-To: rearnsha@cambridge.arm.com
To: gnats-bugs@gnats.netbsd.org
Subject: Kernel forgets that it is ptracing a process
X-Send-Pr-Version: 3.95

>Number:         8564
>Category:       port-arm
>Synopsis:       Kernel forgets that it is ptracing a process
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    port-arm-maintainer
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Oct 06 03:05:00 +0000 1999
>Closed-Date:    Wed Apr 09 15:41:02 +0000 2003
>Last-Modified:  Wed Apr 09 15:41:02 +0000 2003
>Originator:     Richard Earnshaw
>Release:        -current
>Organization:
ARM
-- 
>Environment:

System: NetBSD shark1 1.4K NetBSD 1.4K (SHARK) #46: Thu Sep 30 18:19:47 BST 1999 rearnsha@shark1:/usr/src/sys/arch/arm32/compile/SHARK arm32


>Description:
	When trying to debug a large program that causes much paging/swapping,
	the kernel can forget that it is ptracing a process; this seems to be
	the only possible way that the particular error can be raised in
	response to the following sequence of ptrace calls:

 16213 gdb      CALL  ptrace(PT_READ_I,0x3f56,0x208b9308,0)
 16213 gdb      RET   ptrace 546005000/0x208b6008
 16213 gdb      CALL  ptrace(PT_CONTINUE,0x3f56,0x1,0)
 16213 gdb      RET   ptrace 0
 16213 gdb      CALL  wait4(0xffffffff,0xefbfcfb0,0,0)
 16213 gdb      RET   wait4 16214/0x3f56 (target seg-faults)
 ...
 16213 gdb      CALL  ptrace(33,0x3f56,0xefbfcf30,0)
 16213 gdb      RET   ptrace -1 errno 1 Operation not permitted
 16213 gdb      CALL  ptrace(35,0x3f56,0xefbfcecc,0)
 16213 gdb      RET   ptrace -1 errno 1 Operation not permitted

	Note that on arm32, ptrace(33) is read int-regs; ptrace(35)
	is read fp-regs.  From my reading of the code, these can only 
	generate "Operation not permitted (EPERM)" if the kernel thinks
	the process is not under trace:
                /*
                 * You can't do what you want to the process if:
                 *      (1) It's not being traced at all,
                 */
                if (!ISSET(t->p_flag, P_TRACED))
                        return (EPERM);

	Note also, that the PT_CONTINUE call uses exactly the same check,
	but that succeeds; so the kernel is clearly losing track of the
	P_TRACED setting.

>How-To-Repeat:
	Try to debug a debug version of Mozilla on a SHARK with 32 MBMemeory.
>Fix:
	Sorry, no idea.

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: port-arm32-maintainer->port-arm-maintainer 
Responsible-Changed-By: bjh21 
Responsible-Changed-When: Mon Aug 5 17:45:31 PDT 2002 
Responsible-Changed-Why:  
The arm32 port has disappeared. 
State-Changed-From-To: open->closed 
State-Changed-By: rearnsha 
State-Changed-When: Wed Apr 9 08:38:44 PDT 2003 
State-Changed-Why:  
Closing my own PR.  I suspect this was one of the many pmap-related problems 
that will most likely have been fixed by the substantial restructuring of 
the arm32 pmap code for 1.6.  I'll file another report if I ever come across 
it again. 
>Unformatted:

Home	PR Database Search