home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!mcsun!Germany.EU.net!unido!kommu!norisb!georg
- From: georg@norisb (Georg Biehler)
- Newsgroups: comp.unix.sysv386
- Subject: Re: How to debug a PANIC??
- Message-ID: <512@kommu.UUCP>
- Date: 28 Jul 92 06:08:35 GMT
- References: <1992Jul26.151933.22053@tigger.jvnc.net>
- Sender: news@kommu.UUCP
- Lines: 42
- X-Newsreader: Tin 1.1 PL4
-
- mtcusa@tigger.jvnc.net (Multilingual Technogies Corporation) writes:
- [...]
- :
- : INTERACTIVE:
- :
- [...]
- :
- : Once you get this in the kernel, activate the debugger (CTRL-ALT-D)
- : and set a break point on "panic". You can do this as:
- :
- : panic .i brk0
- [...]
- :
- : If you can produce the panic on demand, do so. If not, wait for
- : it. When it happens, the system will dump all that register muck
- : and then break on the 'panic' kernel call.
-
- Sorry, but for a panic not the old kernel function "panic" gets called,
- but "cmn_err" with CE_PANIC as first parameter. You do not have to set
- a breakpoint on the function, since the kernel debugger stopps automatically
- on panics.
-
- :
- : You can now type 't' for 'trace' and get a backtrace to the
- : system call that caused the panic.
- :
- The command to get a backtrace for the stack is simply "stack".
-
- : GURU question: What is the meaning of all that stuff in
- : parentheses after the system calls. It's not
- : function call arguments. More to the point
- : where can I read for myself about it.
-
- A system call has no direct parameters; the parameters for the call are saved
- somewhere; a pointer to the save area is in the u-area (u.u_ap).
- :
- : Hope this helps.
- :
- : George Bogatko - mtcusa@tigger.jvnc.net
-
- Me too
- -Georg
-