[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