Subject: port-arm32/7122: Breakpoints lost under heavy swapping
To: None <gnats-bugs@gnats.netbsd.org>
From: Richard Earnshaw <rearnsha@cambridge.arm.com>
List: netbsd-bugs
Date: 03/10/1999 17:31:13
>Number:         7122
>Category:       port-arm32
>Synopsis:       Breakpoints lost under heavy swapping
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-arm32-maintainer (NetBSD/arm32 Portmaster)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Mar 10 09:35:00 1999
>Last-Modified:
>Originator:     Richard Earnshaw
>Organization:
ARM
-- 
>Release:        NetBSD-current 19990305
>Environment:
	
System: NetBSD shark1 1.3K NetBSD 1.3K (SHARK) #15: Sat Mar 6 15:01:12 GMT 1999 rearnsha@shark1:/work/rearnsha/netbsd/sys/arch/arm32/compile/SHARK arm32


>Description:
	I've been trying to track down a bug which is causing random 
	seg-faults on my shark when it is swapping heavily and noticed that
	breakpoints set by gdb are not always being honoured.  It would appear
	that a page that has a breakpoint set looses this if the page gets
	swapped out.
	
>How-To-Repeat:
	Attach to a running program with gdb, set a breakpoint and continue
	execution; exercise the system heavily so that the page containing 
	the breakpoint gets swapped out and then arrange for the process 
	under debug to execute the instruction containing the breakpoint.

	Groan with frustration as the system continues to execute through
	the breakpoint and promptly crashes before you have a chance to stop
	it.

	The specific example where I'm seeing this is /bin/sh when it is
	blocked in wait4(); the breakpoint is on the instruction after the
	SWI and the shell is waiting for a process that is causing a lot
	of swapping.  Eventually the sub-process terminates and the breakpoint
	should be hit.  At the time of termination, TOP is showing that the
	process has a RES value of 0 and that it has been swapped
	(name in angle-brackets).
	
>Fix:
	The only work-around I have found so far is to modify the executable
	under test to mlock the page where the breakpoint is needed into 
	physical memory.  The breakpoint can then be set and the system is
	unable to swap the page out.
	
>Audit-Trail:
>Unformatted: