Subject: kern/10175: Deterministic panics from userspace on NetBSD/i386 1.4.2
To: None <gnats-bugs@gnats.netbsd.org>
From: Gregory McGarry <g.mcgarry@ieee.org>
List: netbsd-bugs
Date: 05/22/2000 16:31:17
>Number:         10175
>Category:       kern
>Synopsis:       Normal user can deterministically crash system
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon May 22 16:32:01 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     Gregory McGarry
>Release:        1.4.2
>Organization:
Signal Processing Research Centre
>Environment:
	

NetBSD/i386 1.4.2

>Description:

I'm interested in getting checkpointing working on NetBSD.  I've
started by looking at userspace checkpointing.  I have code which
(should) preserve execution state in an (a.out) executable.  Upon
execution the process recommences execution at the last checkpoint.

When the checkpoint executable is run as a normal user, the system
freezes.

Revealing this finding on port-i386, Martin Huseman <martin@rumolt.teuto.de>
was able to confirm the problem, however, his system developed a panic,
rather than a system freeze:

panic: AMAP_B2SLOT: invalid byte count

backtrace is:

_amap_alloc(1256c,0,1,c2f6df40) at _amap_alloc+0x22
_amap_copy(c2ee8580,c2f66568,1,1,a000,a001) at _amap_copy+0xb6
_uvmfault_amapcopy(c2f6df40,c2ee8580,106,0,0) at _uvmfault_amapcopy+0xc8
_uvm_fault(c2ee8580,a000,0,3,0) at _uvm_fault+0x17f
_trap() at _trap+0x40b

>How-To-Repeat:

The code is available at
http://www.sprc.qut.edu.au/~mcgarry/netbsd/checkpoint.tar.gz
The archive is less than 10KB.

Compile on NetBSD/i386 1.4.2.  The code requires a.out support, so
a -current system may show similar behaviour.
Execute ./main, which will create a ./main.checkpoint file which
(is supposed to) preserve process execution state.  Upon execution
of ./main.checkpoint to restore the process execution, watch the
system freeze or panic.  The problem occurs when the stack is restored
in recover().

>Fix:
	
>Release-Note:
>Audit-Trail:
>Unformatted: