kmem-ps-1.3.95+ magic number?

kmem-ps-1.3.95+ magic number?

Post by Saadiq Rodgers-Kin » Mon, 06 May 1996 04:00:00

I have been running Linux for a few months now and I must admit, I
got*y.  I broke the cardinal rule... If it ain't broke, don't fix
it.  Well, I tried to upgrade kmem-ps-1.3.95+ and I have had very
limited success.  It compiled fine.  Installed fine.  Needless to say,
nothing ran fine.  How's 2 out of 3?  Anywayz, enough *, to the
    I am running Slackware 3.0 w/ kernel 1.3.98 (I updated that in an
attempt to fix my problems).  In the README it says that after
compiling, one should run 'ps -U' to create the psdatabase.  Upon

dread:/usr/src/kmem-ps-1.3.95+# ps -U

    All I got wuz...

/usr/src/linux/ bad magic number

    It also says that you can specify the system binary and the swap
device/file as arguments like so:  ps -U /usr/src/linux/tools/system
/dev/swap   Well, I had no /dev/swap so I made a symbolic link to
/dev/hdb2, where my swap partition is.  I then tried to figure out
where /usr/src/linux/tools/system was.  I had no tools/system in my
linux directory.  In the NEWS file it mentioned being able to use the file but I didn't read that before I attempted copying
vmlinux to tools/system and I got the same thing: bad magic number.
    Now all those little usefuls such as 'ps' and 'w' and 'top' simply
refuse to cooperate no matter how much coercion is attempted.  I have
been reduced to a slobbering newbie and am sufficiently humbled. I now
publicly beg help.  Thanks ahead of time...

-Saadiq Rodgers-King



kmem-ps-1.3.95+ magic number?

Post by Mike Cast » Mon, 06 May 1996 04:00:00

Quote:>    All I got wuz...

>/usr/src/linux/ bad magic number

Just a wild guess here, but since I had similar problems with
dosemu and sysklogd, I *think* I *might* know that the problem

I'm guessing you upgraded your binutils recently. is created by running nm on vmlinux, grepping out a
few things, running thruogh sort, and a few other things.  

Older versions of nm created a 32 bit entry for the first column
of  Current versions create 64 bit.  Many
applications had hard coded their routines that analyze to expect 32 bit entries (in short, when reading each
line, they used scanf with %8x rather than just %x).  

Now, many programs also checked against a few specific things in
the first couple of lines, to make sure was in a
correct format before reading the whole thing.  I assume this
step is failing with ps -U.  There really isn't any "magic
number" with, but more of a magic format.  If you're
sufficient with C, you can probably go in and tweak the code
(preferably to something that works with both 32-64 bit entries).

The dosemu routine for validating seems to work well.
If you have that handy, may want to check that out for ideas.

Alternatively, you could run through sed and strip the
first 8 chars off of each line, but that's not a very good
solution (need to do that every time you build a kernel).  You'd
probably want to create a patch to send back to kmem-ps author,
and get your name on the package as a contributor.  ;->

Mike Castle .-=NEXUS=-.  Life is like a clock:  You can work constantly

    We are all of us living in the shadow of Manhattan.  -- Watchmen