Subject: port-arm32/8564: Kernel forgets that it is ptracing a process
To: None <gnats-bugs@gnats.netbsd.org>
From: Richard Earnshaw <rearnsha@cambridge.arm.com>
List: netbsd-bugs
Date: 10/06/1999 04:18:11
>Number:         8564
>Category:       port-arm32
>Synopsis:       Kernel forgets that it is ptracing a process
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    port-arm32-maintainer (NetBSD/arm32 Portmaster)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Oct  6 03:05:00 1999
>Last-Modified:
>Originator:     Richard Earnshaw
>Organization:
ARM
-- 
>Release:        -current
>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.
	
>Audit-Trail:
>Unformatted: