Getting a stack trace for Pavel (was Re: Interesting code...)

• Date: Sun, 14 Jan 1996 17:01:29 PST
• From:
  Pavel Curtis <pavel@parc.xerox.com>
• Cc: moo-cows@parc.xerox.com
• In-reply-to: Kipp the Kidd's message of "Sun, 14 Jan 1996 13:13:55 PST" <Pine.SOL.3.91.960114160200.2282A-100000@gamera.syr.edu>

Kipp the Kidd writes:
> Jan 14 13:38:25: CHECKPOINTING on M.db.new.#129# finished
> Jan 14 13:40:53: *** PANIC: Caught signal 11
> Jan 14 13:40:53: *** PANIC: Empty expr stack in DECOMPILE!
> Jan 14 13:40:53: *** RECURSIVE PANIC: aborting
> 
> I have no other useful info, except that I was messing with the binary 
> connections and manipulating lists (alot).
> Do you want a copy of my DB again Pavel?

No, but I'd like to see the stack backtrace from a local C debugger pointed at
the core file that should have resulted from this.  Here again is my short
directions (for everyone) on how to get me this information:

1) Check that there's a file named `core' in the directory from which you ran
   the server.  If there isn't, then stop now; we can't get the stack backtrace
   for this panic.  You might try typing `limit coredumpsize unlimited' to your
   UNIX shell before starting the server again; that might help you get a
   `core' file from the next panic.

2) Type either `gdb moo core' or `dbx moo core', depending on which debugger
   exists on your system.  If you don't know, just try these in order until one
   works.

3) At the debugger prompt, type `where' and then `quit'.  Send me the output.

NOTE: Core files can be quite large; you might want to remove the file after
      using the debugger on it.

Thanks!
	Pavel

• Re: Interesting code...
• From: Kipp the Kidd <mcmudge@mailbox.syr.edu>

• Prev: FUP/MPL patches
• Next: Greetings, & some questions...
• Index: MOO-cows
• Thread: MOO-cows