--NzB8fVQJ5HfG6fxh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Dec 16, 2002 at 09:50:29AM -0500, Andrew Brown wrote:
> >> 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?

Umh, can I force it somehow?

> >> 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):
> 
> 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.

So it is..


     -sk

--NzB8fVQJ5HfG6fxh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="ddb2.cap"

db{0}> ps/a
 PID          COMMAND      STRUCT PROC *            UAREA *     VMSPACE/VM_MAP
>22798           idlc         0xe4ad0400         0xe51d9000         0xe4b41260
db{0}> show map/f e4b41260
MAP 0xe4b41260: [0x0->0xbfbfc000]
        #ent=0, sz=0, ref=1, version=10, flags=0x1
        pmap=0xe399bb40(resident=1)

--NzB8fVQJ5HfG6fxh--