5:29 p.m.
Often, I'd like to be able to run one crash command, massage the data
produced, and run follow up commands using the massaged data
A (possibly crazy) example, run the mount command, collect the
superblocks addresses, for each super_block, get the s_inodes list head,
traverse each list head to the inode, for each inode, find it's i_data
(address_space) and get the number of pages.. Now.. sum these up and
print a table of filesystem mounts points and the number of cached pages
for each... Perhaps, I'd even traverse the struct pages to provide a
count of clean and dirty pages for each file system.
I do do this by hand. (i.e. mount > mount.file; perlscript mount.file >
crash-script-step-1, then, back in crash I do ". crash-script-step-1 >
data-file-2; and repeat with more massaging).. This is gross, prone to
error, and not terribly fast.
I'd love to start crash as a child of perl and either use expect (which
is a bit of a hack) or better yet, have some machine interface to crash
(ala gdbmi)...
I know.. it's open source, I should write it myself. I just don't want
to reinvent the wheel, if someone else already has done something like
this.
Perhaps I need to learn sial. But what little sial I've looked at seems
a bit low level for my needs.
Has anyone had much luck using expect with crash?
thanks
- jim
5:40 p.m.
New subject: calling crash from another program (or vice versa)
It is possible that some uber debugger has done it in his local build, but
expect, from my experience, also seems to be lot of work put up for the
non-debug things while getting it to work. I liked pykdump.so better and
does the job with minimal effort. And you always have either quick script
or a standard library of commands while debugging.
Thanks,
Ratnam
On Fri, Dec 11, 2009 at 3:29 PM, James Washer <washer(a)trlp.com> wrote:
Often, I'd like to be able to run one crash command, massage the
data
produced, and run follow up commands using the massaged data
A (possibly crazy) example, run the mount command, collect the
superblocks addresses, for each super_block, get the s_inodes list head,
traverse each list head to the inode, for each inode, find it's i_data
(address_space) and get the number of pages.. Now.. sum these up and
print a table of filesystem mounts points and the number of cached pages
for each... Perhaps, I'd even traverse the struct pages to provide a
count of clean and dirty pages for each file system.
I do do this by hand. (i.e. mount > mount.file; perlscript mount.file >
crash-script-step-1, then, back in crash I do ". crash-script-step-1 >
data-file-2; and repeat with more massaging).. This is gross, prone to
error, and not terribly fast.
I'd love to start crash as a child of perl and either use expect (which
is a bit of a hack) or better yet, have some machine interface to crash
(ala gdbmi)...
I know.. it's open source, I should write it myself. I just don't want
to reinvent the wheel, if someone else already has done something like
this.
Perhaps I need to learn sial. But what little sial I've looked at seems
a bit low level for my needs.
Has anyone had much luck using expect with crash?
thanks
- jim
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
5:02 a.m.
James Washer wrote:
Often, I'd like to be able to run one crash command, massage the
data
produced, and run follow up commands using the massaged data
From the example you give I think a SIAL or Python script
<http://sourceforge.net/projects/pykdump/> is what
you want. As for using Perl I guess you are welcome to write
the appropriate module :)
Has anyone had much luck using expect with crash?
We use Expect internally for some very simple things that could
probably be done with "crash -i". It works fine but for anything
not trivial it becomes a bit too hacky I think.
7:40 a.m.
Jim -
Indraneel Mukherjee (mukherjee.indraneel(a)gmail.com) posted these to the
lkcd mailing list some time ago. You might want to look at some of those
- there's one about mounts and one about SBs.
Sial does not provide reentrancy back to crash. On the plus side, you
can pretty much cut&paste kernel code straight into you script, so you
don't have to be a kernel guru to get the info you want. A good source
of code is the /proc hooks that are employed throughout kernel and
driver code... :)
-Luc
-----Original Message-----
From: crash-utility-bounces(a)redhat.com
[mailto:crash-utility-bounces@redhat.com] On Behalf Of James Washer
Sent: Friday, December 11, 2009 6:29 PM
To: Discussion "list for crash utility usage,maintenance and
development
Subject: [Crash-utility] calling crash from another program
(or vice versa)
Often, I'd like to be able to run one crash command, massage
the data produced, and run follow up commands using the massaged data
A (possibly crazy) example, run the mount command, collect
the superblocks addresses, for each super_block, get the
s_inodes list head, traverse each list head to the inode, for
each inode, find it's i_data
(address_space) and get the number of pages.. Now.. sum these
up and print a table of filesystem mounts points and the
number of cached pages for each... Perhaps, I'd even traverse
the struct pages to provide a count of clean and dirty pages
for each file system.
I do do this by hand. (i.e. mount > mount.file; perlscript
mount.file > crash-script-step-1, then, back in crash I do ".
crash-script-step-1 > data-file-2; and repeat with more
massaging).. This is gross, prone to error, and not terribly fast.
I'd love to start crash as a child of perl and either use
expect (which is a bit of a hack) or better yet, have some
machine interface to crash (ala gdbmi)...
I know.. it's open source, I should write it myself. I just
don't want to reinvent the wheel, if someone else already has
done something like this.
Perhaps I need to learn sial. But what little sial I've
looked at seems a bit low level for my needs.
Has anyone had much luck using expect with crash?
thanks
- jim
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
Confidentiality Notice: This e-mail (including any attachments) is intended only for the
recipients named above. It may contain confidential or privileged information and should
not be read, copied or otherwise used by any other person. If you are not a named
recipient, please notify the sender of that fact and delete the e-mail from your system.
10:21 a.m.
Thanks all.. I take a look at the various options recommended.
On Mon, 2009-12-14 at 08:40 -0500, Chouinard, Luc wrote:
Jim -
Indraneel Mukherjee (mukherjee.indraneel(a)gmail.com) posted these to the
lkcd mailing list some time ago. You might want to look at some of those
- there's one about mounts and one about SBs.
Sial does not provide reentrancy back to crash. On the plus side, you
can pretty much cut&paste kernel code straight into you script, so you
don't have to be a kernel guru to get the info you want. A good source
of code is the /proc hooks that are employed throughout kernel and
driver code... :)
-Luc
> -----Original Message-----
> From: crash-utility-bounces(a)redhat.com
> [mailto:crash-utility-bounces@redhat.com] On Behalf Of James Washer
> Sent: Friday, December 11, 2009 6:29 PM
> To: Discussion "list for crash utility usage,maintenance and
> development
> Subject: [Crash-utility] calling crash from another program
> (or vice versa)
>
> Often, I'd like to be able to run one crash command, massage
> the data produced, and run follow up commands using the massaged data
>
> A (possibly crazy) example, run the mount command, collect
> the superblocks addresses, for each super_block, get the
> s_inodes list head, traverse each list head to the inode, for
> each inode, find it's i_data
> (address_space) and get the number of pages.. Now.. sum these
> up and print a table of filesystem mounts points and the
> number of cached pages for each... Perhaps, I'd even traverse
> the struct pages to provide a count of clean and dirty pages
> for each file system.
>
> I do do this by hand. (i.e. mount > mount.file; perlscript
> mount.file > crash-script-step-1, then, back in crash I do ".
> crash-script-step-1 > data-file-2; and repeat with more
> massaging).. This is gross, prone to error, and not terribly fast.
>
> I'd love to start crash as a child of perl and either use
> expect (which is a bit of a hack) or better yet, have some
> machine interface to crash (ala gdbmi)...
>
> I know.. it's open source, I should write it myself. I just
> don't want to reinvent the wheel, if someone else already has
> done something like this.
>
> Perhaps I need to learn sial. But what little sial I've
> looked at seems a bit low level for my needs.
>
> Has anyone had much luck using expect with crash?
>
> thanks
>
> - jim
>
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>
>
Confidentiality Notice: This e-mail (including any attachments) is intended only for the
recipients named above. It may contain confidential or privileged information and should
not be read, copied or otherwise used by any other person. If you are not a named
recipient, please notify the sender of that fact and delete the e-mail from your system.
email message attachment
> -------- Forwarded Message --------
> From: Luc Chouinard <lucchouina(a)yahoo.com>
> To: Chouinard, Luc <Luc.Chouinard(a)trueposition.com>
> Subject: Fw: [lkcd-devel] Some additional SIAL scripts for lkcdutils
> Date: Thu, 24 Sep 2009 07:35:20 -0500
>
>
> ----- Forwarded Message ----
> From: Indraneel Mukherjee <mukherjee.indraneel(a)gmail.com>
> To: lkcd-devel(a)lists.sourceforge.net
> Sent: Thursday, September 24, 2009 7:32:12 AM
> Subject: [lkcd-devel] Some additional SIAL scripts for lkcdutils
>
> Hi,
> We wrote some additional SIAL scripts for lkcdutils.
>
> Details:
> ---------
>
> 1. files.sial - Similar to the 'sfiles' command listing info on open files
for processes in the dump.
> 2. inodeinfo.sial - Prints detailed info for the given inode number of a given
superblock in the dump.
> 3. lsmount.sial - List the mounted file systems in the dump.
> 4. meminfo.sial - Similar to /proc/meminfo.
> 5. mutexinfo - Shows the owner and waiting processes for a given mutex address.
> 6. psched.sial - Similar to /proc/$PID/sched
> 7. superblkinfo.sial - Lists all the fs superblocks and the associated inodes.
>
> They've been tested on lcrash dumps for linux-2.6.22 through 26 for ARM
architecture.
>
> Can these be added to the lkcdutils svn repo?
>
> Warm Regards,
> Indro
>
> plain text document attachment (ATT1316106.txt), "ATT1316106.txt"
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
5731
days inactive
5734
days old
devel@lists.crash-utility.osci.io
4 comments
4 participants
participants (4)
-
Adrien Kunysz -
Chouinard, Luc -
James Washer -
Ratnam Tatavarty