[Crash-utility] Re: Crash-utility Digest, Vol 10, Issue 2

Hariharan T.S. linux.bulletin at gmail.com
Thu Jul 6 11:46:07 UTC 2006


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 at redhat.com <
crash-utility-request at redhat.com> wrote:
>
> Send Crash-utility mailing list submissions to
>        crash-utility at 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 at redhat.com
>
> You can reach the person managing the list at
>        crash-utility-owner at 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 at in.ibm.com>
> Subject: [Crash-utility] why gdb backtracing not being used in crash
> To: anderson at redhat.com
> Cc: crash-utility at redhat.com
> Message-ID: <20060705095546.GA1761 at 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 at 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 at redhat.com>
> Message-ID: <44ABBCD1.9A3EB28B at 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 at redhat.com>
> Subject: [Crash-utility] Re: bt -f fix for s390(x)
> To: Michael Holzheu <holzheu at de.ibm.com>
> Cc: crash-utility at redhat.com
> Message-ID: <44ABDADF.8657728E at 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 at redhat.com>
> Subject: [Crash-utility] Re: why gdb backtracing not being used in
>        crash
> To: rachita at in.ibm.com
> Cc: crash-utility at redhat.com
> Message-ID: <44ABDD11.C5BEFDF1 at 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>
>
> End of Crash-utility Digest, Vol 10, Issue 2
> ********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20060706/3738f43b/attachment.htm>


More information about the Crash-utility mailing list