>> what does the traceback in ddb look like?  do you get a crash dump?
>
>Traceback attached, and no crash dump.

how bizarre.  nothing like the code path that led to my panic, except
at the end where it panics.

can you make a crash dump, or does the machine have trouble doing that?

>> can you build a kernel with -g so that gdb can do full port-mortem
>> debugging?
>
>Sure.
>
>Anything to do in ddb that can help? (I can do that immediately because I
>haven't rebooted the machine yet)

"ps/a" in ddb will show stuff like this (this is from an alpha, so the
pointers are wider):

   db> ps/a
    PID     COMMAND      STRUCT PROC *            UAREA *     VMSPACE/VM_MAP
    296       getty 0xfffffc000298f1d0 0xfffffe0016b1c000 0xfffffc0002998120
    270        cron 0xfffffc000362dac0 0xfffffe0016e56000 0xfffffc0002998fc0
    265       inetd 0xfffffc000ad72ee8 0xfffffe0016e6a000 0xfffffc0002999680
   ...

from your ps output:

   db{0}> ps
    PID        PPID       PGRP        UID S   FLAGS          COMMAND    WAIT
   >22798     22758      11496          0 7 0x180006             idlc
    22758     22757      11496          0 3 0x84086             idlc  select
    22757     22686      11496          0 3 0x84086             tcsh   pause
   ...

process 22798 is the running process.  the traceback shows it's in the
middle of execve().  if you can get the vm_map pointer for that
process and do a "show map/f nnnnn" on it, that would be great.

i fear, however, that the process has already had its vmspace
eliminated, and it will be empty.  let's see, though.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."