--- /usr/src/redhat/BUILD/crash-4.0-2.30/filesys.c 2006-06-06 21:46:32.000000000 +0200
+++ filesys.c 2006-07-06 13:43:57.000000000 +0200
@@ -1144,6 +1144,7 @@ cmd_mount(void)
ulong vfsmount = 0;
int flags = 0;
int save_next;
+ int mh_flag=1;
while ((c = getopt(argcnt, args, "if")) != EOF) {
switch(c)
@@ -1202,7 +1203,11 @@ cmd_mount(void)
sscanf(buf2,"%lx",&vfsmount);
show_mounts(vfsmount, flags);
} else {
+ if(mh_flag)
+ {
fprintf(fp, mount_hdr);
+ mh_flag=0;
+ }
fprintf(fp, buf2);
}
found = FALSE;
Regards
Hariharan T.S.
Send Crash-utility mailing list submissions to
crash-utility@redhat.com
To subscribe or unsubscribe via the World Wide Web, visit
https://www.redhat.com/mailman/listinfo/crash-utility
or, via email, send a message with subject or body 'help' to
crash-utility-request@redhat.com
You can reach the person managing the list at
crash-utility-owner@redhat.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Crash-utility digest..."
Today's Topics:
1. why gdb backtracing not being used in crash (Rachita Kothiyal)
2. Re: Crash : To improve readability of mount command inCrash.
(Dave Anderson)
3. Re: bt -f fix for s390(x) (Dave Anderson)
4. Re: why gdb backtracing not being used in crash (Dave Anderson)
----------------------------------------------------------------------
Message: 1
Date: Wed, 5 Jul 2006 15:25:46 +0530
From: Rachita Kothiyal <rachita@in.ibm.com >
Subject: [Crash-utility] why gdb backtracing not being used in crash
To: anderson@redhat.com
Cc: crash-utility@redhat.com
Message-ID: <20060705095546.GA1761@in.ibm.com>
Content-Type: text/plain; charset=us-ascii
Hi Dave
I was wondering why in crash we are not using the already existing
bt via the gdb_interface(). I see it being used in case of alpha
and ppc64, but am not sure if it works. Could you please throw some
light on the rationale behind this...
Thanks
Rachita
------------------------------
Message: 2
Date: Wed, 05 Jul 2006 09:21:21 -0400
From: Dave Anderson <anderson@redhat.com>
Subject: Re: [Crash-utility] Crash : To improve readability of mount
command inCrash.
To: "Discussion list for crash utility usage, maintenance and
development" <crash-utility@redhat.com>
Message-ID: < 44ABBCD1.9A3EB28B@redhat.com>
Content-Type: text/plain; charset="us-ascii"
"Hariharan T.S." wrote:
> Hi All Just a suggestion for improved readablity in crash for mount command.Instead of printing header every time for
> each line, It can be limited to one header at the top.crash> mount /VFSMOUNT SUPERBLK TYPE DEVNAME DIRNAME1100800
> 10ec800 rootfs rootfs /VFSMOUNT SUPERBLK TYPE DEVNAME DIRNAME1100200 10e9400 ext3 /dev/root /crash> mount
> /procVFSMOUNT SUPERBLK TYPE DEVNAME DIRNAME1100280 10ec400 proc /proc /procVFSMOUNT SUPERBLK TYPE DEVNAME
> DIRNAME1100f00 10ec400 proc /proc /proccrash> RegardsHariharan T.S.
What -- no patch to fix it? ;-)
Yeah, those are unique cases, because even though you
are requesting just one directory via the extra command line
argument, there are two unique vfsmount entries, i.e,
the rootfs and ext3 types for the / directory. (I can't
reproduce the two /proc entries as in your example.)
Anyway, there should be a flag set somewhere to avoid
the duplicate headers. I'll add it to the crash.TODO list:
http://people.redhat.com/anderson/crash.TODO.html
Thanks,
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.redhat.com/archives/crash-utility/attachments/20060705/57de55bc/attachment.html
------------------------------
Message: 3
Date: Wed, 05 Jul 2006 11:29:35 -0400
From: Dave Anderson < anderson@redhat.com>
Subject: [Crash-utility] Re: bt -f fix for s390(x)
To: Michael Holzheu <holzheu@de.ibm.com>
Cc: crash-utility@redhat.com
Message-ID: <44ABDADF.8657728E@redhat.com>
Content-Type: text/plain; charset=us-ascii
Michael Holzheu wrote:
> Hi Dave,
>
> Here comes a fix for the bt -f command.
>
> The problem is that when the backchain is invalid on s390(x) we can get huge values for the stackframe size. This can lead to a termination of crash with a SIGSEGV. To fix this, we have to use in case of an invalid backchain the difference between the current backchain and the end of the stack as stackframe size.
>
> ---
>
Thanks Michael -- queued for the next release.
Dave
>
> diff -Naur crash-4.0-2.31/s390.c crash-4.0-2.31-s390-bt-f.fix/s390.c
> --- crash-4.0-2.31/s390.c 2006-06-27 16:15: 32.000000000 +0200
> +++ crash-4.0-2.31-s390-bt-f.fix/s390.c 2006-07-03 16:37:34.000000000 +0200
> @@ -714,7 +714,9 @@
> frame_size = stack_base - old_backchain
> + KERNEL_STACK_SIZE;
> } else {
> - frame_size = backchain - old_backchain;
> + frame_size = MIN((backchain - old_backchain),
> + (stack_base - old_backchain +
> + KERNEL_STACK_SIZE));
> }
> for(j=0; j< frame_size; j+=4){
> if(j % 16 == 0){
> diff -Naur crash-4.0-2.31/s390x.c crash-4.0-2.31-s390-bt-f.fix/s390x.c
> --- crash-4.0-2.31/s390x.c 2006-06-27 16:15:32.000000000 +0200
> +++ crash-4.0-2.31-s390-bt-f.fix/s390x.c 2006-07-03 16:37: 37.000000000 +0200
> @@ -747,7 +747,9 @@
> frame_size = stack_base - old_backchain
> + KERNEL_STACK_SIZE;
> } else {
> - frame_size = backchain - old_backchain;
> + frame_size = MIN((backchain - old_backchain),
> + (stack_base - old_backchain +
> + KERNEL_STACK_SIZE));
> }
> for(j=0; j< frame_size; j+=4){
> if(j % 16 == 0){
------------------------------
Message: 4
Date: Wed, 05 Jul 2006 11:38:57 -0400
From: Dave Anderson <anderson@redhat.com>
Subject: [Crash-utility] Re: why gdb backtracing not being used in
crash
To: rachita@in.ibm.com
Cc: crash-utility@redhat.com
Message-ID: < 44ABDD11.C5BEFDF1@redhat.com>
Content-Type: text/plain; charset=us-ascii
Rachita Kothiyal wrote:
> Hi Dave
>
> I was wondering why in crash we are not using the already existing
> bt via the gdb_interface(). I see it being used in case of alpha
> and ppc64, but am not sure if it works. Could you please throw some
> light on the rationale behind this...
>
> Thanks
> Rachita
I could never get it to work, except "sort-of" on alpha. But even
on alpha, it would only go back as far as the first kernel exception
frame, and then would go off into the weeds. I don't know anything
about the ppc64 -- you can ask Haren about that...
As I recall, there was a whole bunch of user environment stuff
that needed to be faked/replicated for it to even come close to
working correctly, i.e., stuff that gdb would be gathering when
running on a user process.
Dave
------------------------------
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
End of Crash-utility Digest, Vol 10, Issue 2
********************************************