Third time this week I've found zen sitting in ddb> 

I'm running the Feb22 tar_files plus

/sys/vm/vm_object.c:
     $NetBSD: vm_object.c,v 1.45 1997/02/25 23:28:09 thorpej Exp $
/sys/vm/vm_map.c:
     $NetBSD: vm_map.c,v 1.26 1997/02/25 23:27:08 thorpej Exp $

and Charles' latest com driver.

This time it was:

kernel: page fault trap, code=0
Stopped at _vm_fault+0x59: movw	0x22(%esi),%ax
ddb> trace
_vm_fault(f8747700,4c000,3,0) at _vm_fault+0x59
_trap() at _trap+0x48f
--- trap (number 6) ---
0xa284:
ddb>

and of course I could not find my print out of the ddb man page so
that's about all the info I have.
Normally entering 'c' gets me a core dump, but not this time, and of
course I could not remember a 'call xxxx' to force one.

I'll look in the FAQ shortly, but it it isn't there, I personally
would really appreciate a "here are the useful things to do when your
NetBSD system drops you into ddb..." the above info doesn't seem
enough for a pr?

Possibly related to the above, this morning most of my cron jobs
reported segmentation faults and I have:

-rw-------  1 sjg    users      74040 Mar  8 03:15 /d2/users/sjg/sh.core
-rw-------  1 root   wheel      90436 Mar  8 03:02 /var/log/sh.core
-rw-------  1 root   wheel     123216 Mar  8 02:22 /var/log/sed.core
-rw-------  1 root   bin       123192 Mar  8 02:08 /etc/apc/run/sh.core
-rw-------  1 root   wheel      16672 Mar  8 02:04 /var/log/basename.core
-rw-------  1 stats  stats      16672 Mar  8 02:02 /d2/stats/basename.core
-rw-------  1 root   nobody    143708 Mar  8 02:00 /var/tmp/find.core
-rw-------  1 root   wheel       8456 Mar  8 02:00 /var/preserve/find.core
-rw-------  1 root   wheel     246108 Mar  8 02:00 /usr/local/domain/named.core

The top one is interesting? the mail from cron says:

/users/sjg/cron/hourly.sh: 249: Syntax error: ";;" unexpected (expecting "fi")

which is incorrect. (That hourly.sh is a symlink to my rc.sh which runs
every hour on at least 100 machines running just about every flavour
of unix, so its not just my opinion :-)

A smaple of gdb sh sh.core's showed no pattern.  I've just recompiled
sh with -g (I'll submit some pr's shortly to change the *.mk macros so
this can be done more easily), so next time I might be able to gather
more info.

--sjg