[Crash-utility] Re: [RFC] Crash extension for SystemTap

Satoru MORIYA satoru.moriya.br at hitachi.com
Fri Jun 22 13:41:09 UTC 2007


Hi Dave,

Thank you so much for your review and crash-4.0-4.2.
And I am sorry for delaying my reply for a long time.

I updated my extension for crash-4.0-4.2.


Dave Anderson wrote:
 > The systemtaplog_init() function must be renamed "_init()" in order
 > for it to be called when the dlopen() call is made.  Otherwise,
 > the extend command fails because no commands get registered:

OK, I changed systemtaplog_init() to _init().

 > The only other thing that makes me a little nervous is the temporary
 > relocation of the setjmp buffer.  That was never meant to be used
 > by individual commands -- although nothing prevents it.  I see that it
 > is used to force your cleanup() routine to be called.  And your
 > cleanup() routine exists to free() the subbuf buffer and fclose()
 > the outfp.  A couple suggestions:
 >
 > (1) if you use GETBUF() instead of malloc(), then the buffer will get freed
 >     automatically by restore_sanity() prior to the next command prompt
 > -- even
 >     if you don't do an accompanying FREEBUF().
 > (2) with respect to the outfp file pointer, you could recognize whether it
 >     was left open when the command runs again, and fclose() it then.  Worse
 >     case, a single file pointer would be left open for the remainder of the
 >     crash session.
 >

That's right, and I agreed with you. I'll stop relocation and implement this
part based on your suggestions.

 > [...]So perhaps I could simply allow modules to register an additional
 > command with a new "CLEANUP" flag, which would not show up on the help
 > menu, but would be called during restore_sanity() prior to each
 > command prompt.

Thanks to the new function of crash-4.0-4.2, I can register an cleanup
routine of my extension. And I changed setup_global_data() to use
symbol_value_module() which was introduced in crash-4.0-4.2 instead of
my original function.

Additionally, I changed command option. I removed -m option and added
-o option. I can specify the output directory using -o option.

You can use this extension like this:

Preparation
==============
(A) Build the shared-object(stplog.so).

1. Install crash-devel package.
     $ rpm -ivh crash-devel

2.  $ cd libcrash_for_systemtap

3. Build
     $ make

(B) Make the crash dump which includes SystemTap trace data.
     (*)If you analyze the live system memory, ignore this section.

1. Install kdump
      If you use FC6, see following URL.
      http://fedoraproject.org/wiki/FC6KdumpKexecHowTo?highlight=%28kdump%29

2. Use SystemTap on bulkmode
     $ stap -b foo.stp

3. Panic
     $ echo c > /proc/sysrq-trigger

How to use
==============
1. start crash
     $ crash vmlinux vmcore
     (*) If you analyze the live system memory, you don't have to enter vmcore.

2. load the shared-object
     crash> extend $(WHERE_OBJ_PLACED)/stplog.so

3. retrieve the data
     crash> stplog -o output_dir mod_name

4. You can get output files under output_dir directory.


Output
==============
stplog command makes a file per cpu buffer of relayfs. Of cause, it also
removes the padding bytes in the subbufs of relayfs automatically.

Best Regards,
-- 
---
Satoru MORIYA
Linux Technology Center
Hitachi, Ltd., Systems Development Laboratory
E-mail: satoru.moriya.br at hitachi.com
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: stplog.c
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20070622/41bb61e6/attachment.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Makefile
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20070622/41bb61e6/attachment.ksh>


More information about the Crash-utility mailing list