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

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&gt; 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&gt; 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&gt; 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&gt; Message-ID: <44ABBCD1.9A3EB28B(a)redhat.com&gt; 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&gt; Subject: [Crash-utility] Re: bt -f fix for s390(x) To: Michael Holzheu <holzheu(a)de.ibm.com&gt; Cc: crash-utility(a)redhat.com Message-ID: <44ABDADF.8657728E(a)redhat.com&gt; 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&gt; 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&gt; 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 ********************************************