>Number:         7897
>Category:       kern
>Synopsis:       1.4-branch kernel crash in amap_copy()
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people (Kernel Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jul  3 01:50:01 1999
>Last-Modified:
>Originator:     Chris Demetriou
>Organization:
>Release:        1.4-branch as of 2-3hours ago.
>Environment:
NetBSD speedy 1.4 NetBSD 1.4 (SPEEDY) #1: Sat Jul  3 00:36:11 PDT 1999     cgd@speedy:/a/src/src-1-4-branch/sys/arch/i386/compile/SPEEDY i386
userland, including X server and libraries, from the NetBSD/i386 1.4
distribution sets.  Relevant packages:
ghostscript-5.50    Aladdin Postscript interpreter.
gv-3.5.8            A PostScript and PDF previewer.

>Description:
The NetBSD 1.4-branch kernel i'm running (compiled from sources checked
out this evening) crashes in uvm's amap_copy() function.

The relevant bits of the dmesg info are:

uvm_fault(0xf4a87a54, 0x0, 0, 3) -> 1
fatal page fault in supervisor mode
trap type 6 code 2 eip f01cd016 cs 8 eflags 10202 cr2 0 cpl 0
panic: trap

That eip (PC) is in the UVM amap_copy() function.  Unfortunately, since
gdb on the i386 isn't capable of generating stack traces through trap
entries, I can't easily provide a complete stack trace.
>How-To-Repeat:
This happens fairly reliably for me (66% of the time, or so)
when I try to run 'gv' on a particular large PostScript file:

	ftp://ftp.netbsd.org/pub/NetBSD/misc/dec-docs/ec-qd2ka-te.ps.gz

After downloading it and un-gzipping it, i start up gv on it.
gv complains about something like not being able to allocate space
for backing store for the window, then the system either crashes
and dumps a core or hangs for a while with the disk activity light
on, then 'wakes up' with the X server entirely dead.  (In that case,
the X server is reported to be killed because the system has run
out of swap.  Attempting the same test again seems to randomly yeild
one of the two results.  If at first you don't succeed... 8-)

The system has 64MB of memory, and is configured to have just over 256MB
of swap.  It's possible that the X server and gv are running
out of memory+swap, but it seems unreasonable.  My display is
1600x1200x8bpp, so even if it has to allocate a _bunch_ of
pixmaps the size of the entire display, it should be OK!

I can provide kernel crash dumps for people interested in hunting
down the problem, and since it seems I can reproduce this pretty
easily I can try to test fixes.
>Fix:
???
>Audit-Trail:
>Unformatted: