Best of the Newsgroups: osr5 using scodb

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):

From: Bela Lubkin <belal@sco.com>
Subject: using scodb for various purposes, Re: 5.0.6 grinds to a complete halt
Date: Thu, 20 May 2004 08:34:07 GMT
Message-ID: <20040520083407.GT10272@sco.com> 
References: <O1ymc.18442$urx.4433@news04.bloor.is.net.cable.rogers.com> <20040507002147.GG10272@sco.com> <mKgoc.43839$n7P1.28035@twister01.bloor.is.net.cable.rogers.com> <d3e78b1d.0405190813.3c671b7f@posting.google.com> 


Barry Swane wrote:

> Some questions re the debugger- which I have now configured.
> If the disk has stopped-- am I likely to get anything back from the
> debugger?

Yes.  Oh, there may be some cases where a disk hang would stop the
kernel as a whole, but that would be unusual.  You've already described
symptoms where the kernel is clearly still running (you can type and
edit an input line); under those conditions, scodb will definitely be
helpful.

> I assume this can only be run from the system console-- I can't do it
> remotely?

OpenServer includes two different items named "scodb".

There's the kernel debugger driver, enabled by putting 'Y' in
/etc/conf/sdevice.d/scodb, relinking the kernel and rebooting.  To get
into that, you must be sitting at the system console.  Note that the
console can be either the local video card multiscreens, or a serial
port.  I like to use something I call the "buddy system", described on:

  http://groups.google.com/groups?selm=9804061301.aa02092@vagabond.armory.com

scodb only supports standard ASCII over a serial port, so it has no way
to observe a sequence like Ctrl-Alt-D; the default debugger key on a
serial port is Ctrl-X.

There's also the scodb(ADM) command (/etc/scodb).  This is basically a
recompilation of the scodb driver as a user-level program.  It can read
and write kernel memory, but cannot affect flow of control (for instance
it can't set breakpoints nor be invoked when a breakpoint -- or panic --
is hit).  It can also be run to examine a saved crash dump.

> I imagine that, in order to get info from the debugger, root must
> already be logged in, and sitting at # prompt?

If it's linked in, the in-kernel debugger can be invoked at any time
from the console, regardless of who's logged in (including nobody).
Exception: you can invoke it from a graphical screen like X, but it
doesn't do anything to put the screen back in text mode, nor display
itself in graphics.  You can do simple interactions (like "whoops, I
just hit Ctrl-Alt-D and the whole system hung ... type 'q' Return ...
ah, we're back).  There may be a similar situation on a serial port, but
it's much more obscure: OSR5 supports a "scan code mode" where, with a
suitable terminal, programs _can_ see things like Ctrl and Alt being
pressed and released.  I've never tried scodb under those circumstances,
but I bet it would go wrong.  Hardly anything uses scancode mode.

In order to run user-level scodb, you must be logged in as root.  This
would be impossible if the disk subsystem had already hung.  However, if
you were _already running_ scodb by the time of the hang, you might get
away with it.  So experiment with that -- open an ssh session to the
machine, run `/etc/scodb -w`, leave it that way until the hang happens.
See if you can interact.  Two possible impediments: (1) if memory is
overcommitted, pages of your idle process will have been pushed out to
swap and it'll hang trying to retrieve them; (2) scodb may not have
faulted in all the pages of its own executable image.  #2 could be a big
problem.  To stack the deck in your favor, when you first start the
session, briefly use all the scodb commands you're likely to use later.

> I am trying to experiment with the debugger in advance of the
> freeze-up, to try to get a little bit familiar with it:
> i)  if I hold CTRL-ALT-D - it just logs me out, as if I had pressed
> CTRL-D

You mentioned that you were coming in remotely, so that's not going to
work.  If you use the "buddy system" you'll be coming in (ssh or telnet)
to a machine _next to_ the problem machine, then running a serial comm
program to the problem machine.  Then you'll be able to pop up the real
in-kernel debugger (but the key will be Ctrl-X, not Ctrl-Alt-D).

> ii)  I can load scodb, from shell prompt
>     If I enter "stack" command, I get
> When operating on /dev/mem, you cannot examine the stack of the
> current process.  The "stack" command must be used with the "-p"
> argument.
> If I enter "stack -p", I get the same message

Use "?" for scodb's internal help.  On the "stack" command it says:

  stack [stack_addr|-p pid|-p proc_addr]  Stack backtrace

Try "stack -p 1".

The notion of "current process" doesn't make sense in the context of
user-level scodb.  If you break into in-kernel scodb, you've (usually)
interrupted some process that was doing its thing.  Commands like
"stack" can then show you what that process was doing.  In user-level
scodb, at all times when scodb can read information out of the kernel,
scodb itself is the running process.  Looking at the workings of the
debugger process itself might be somewhat interesting, but it's almost
never what you set out to do.  So you have to tell it what process you
care about.  (It could, probably should, be enhanced to have a way to
inform it: "nevermind all that, the process I am generally interested in
is #1234; pretend I've specified that in all commands that care".  But
that doesn't exist in the current /etc/scodb.)

> Can someone point me to documentation on scodb?  man scodb makes
> reference to the SCODB User's Guide.  I thought I had a complete set
> of manuals- but I don't have that one.

Again, this is a good question which I will respond to in a third
separate message so it can more easily be found in the future.

>Bela<

Buy Take Control of the Mac Command Line with Terminal

Buy Take Control: The Mac OS X Lexicon

Buy Take Control of Screen Sharing in Leopard

Buy Take Control of Permissions in Leopard

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.