Re: [Crash-utility] Crash : To improve readability of mount command in Crash
by Lin Feng Shen
> Date: Wed, 05 Jul 2006 09:21:21 -0400
> From: Dave Anderson <anderson(a)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(a)redhat.com>
> Message-ID: <44ABBCD1.9A3EB28B(a)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
Here is a patch against crash-4.0-25.4 on SLES10_RC3.
===================
From: Lin Feng Shen <shenlinf(a)cn.ibm.com>
The patch improves readablity in crash for mount command. Instead of
printing header for each mount point in "mount [vfsmount | superblock
| devname | dirname | inode]", it showes an unique one.
Signed-off-by: Lin Feng Shen <shenlinf(a)cn.ibm.com>
---
diff -upNr crash-4.0-2.18.orig/filesys.c crash-4.0-2.18/filesys.c
--- crash-4.0-2.18.orig/filesys.c 2006-07-05
23:46:09.000000000 -0400
+++ crash-4.0-2.18/filesys.c 2006-07-05 23:53:41.000000000
-0400
@@ -1144,6 +1144,7 @@ cmd_mount(void)
ulong vfsmount = 0;
int flags = 0;
int save_next;
+ int unique_mount_hdr=0;
while ((c = getopt(argcnt, args, "if")) != EOF) {
switch(c)
@@ -1202,7 +1203,10 @@ cmd_mount(void)
sscanf(buf2,"%lx",&vfsmount);
show_mounts(vfsmount, flags);
} else {
- fprintf(fp, mount_hdr);
+ if (unique_mount_hdr == 0){
+ fprintf(fp, mount_hdr);
+ unique_mount_hdr = 1;
+ }
fprintf(fp, buf2);
}
found = FALSE;
18 years, 4 months
Re: Crash-utility Digest, Vol 10, Issue 2
by Hariharan T.S.
Hi Dave,
Patch for the Message 2 of *Crash-utility Digest, Vol 10, Issue 2*
"To improve readability of mount command in Crash"
--- /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.
On 7/5/06, crash-utility-request(a)redhat.com <
crash-utility-request(a)redhat.com> wrote:
>
> Send Crash-utility mailing list submissions to
> crash-utility(a)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(a)redhat.com
>
> You can reach the person managing the list at
> crash-utility-owner(a)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(a)in.ibm.com>
> Subject: [Crash-utility] why gdb backtracing not being used in crash
> To: anderson(a)redhat.com
> Cc: crash-utility(a)redhat.com
> Message-ID: <20060705095546.GA1761(a)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(a)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(a)redhat.com>
> Message-ID: <44ABBCD1.9A3EB28B(a)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/57de55...
>
> ------------------------------
>
> Message: 3
> Date: Wed, 05 Jul 2006 11:29:35 -0400
> From: Dave Anderson <anderson(a)redhat.com>
> Subject: [Crash-utility] Re: bt -f fix for s390(x)
> To: Michael Holzheu <holzheu(a)de.ibm.com>
> Cc: crash-utility(a)redhat.com
> Message-ID: <44ABDADF.8657728E(a)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(a)redhat.com>
> Subject: [Crash-utility] Re: why gdb backtracing not being used in
> crash
> To: rachita(a)in.ibm.com
> Cc: crash-utility(a)redhat.com
> Message-ID: <44ABDD11.C5BEFDF1(a)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(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>
>
> End of Crash-utility Digest, Vol 10, Issue 2
> ********************************************
>
18 years, 4 months
why gdb backtracing not being used in crash
by Rachita Kothiyal
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
18 years, 4 months
bt -f fix for s390(x)
by Michael Holzheu
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.
---
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){
18 years, 4 months
Crash : To improve readability of mount command in Crash.
by Hariharan T.S.
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 DIRNAME
1100800 10ec800 rootfs rootfs /
VFSMOUNT SUPERBLK TYPE DEVNAME DIRNAME
1100200 10e9400 ext3 /dev/root /
crash> mount /proc
VFSMOUNT SUPERBLK TYPE DEVNAME DIRNAME
1100280 10ec400 proc /proc /proc
VFSMOUNT SUPERBLK TYPE DEVNAME DIRNAME
1100f00 10ec400 proc /proc /proc
crash>
Regards
Hariharan T.S.
18 years, 4 months
