Bug 1262589 - gstack in DTS defaults to "/usr/bin/gdb"
Summary: gstack in DTS defaults to "/usr/bin/gdb"
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Developer Toolset
Classification: Red Hat
Component: gdb
Version: DTS 3.0 RHEL 6
Hardware: All
OS: Linux
unspecified
low
Target Milestone: alpha
: 4.0
Assignee: Jan Kratochvil
QA Contact: Miroslav Franc
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-09-13 03:17 UTC by Frank Hirtz
Modified: 2019-08-15 05:24 UTC (History)
6 users (show)

Fixed In Version: devtoolset-4-gdb-7.10-17.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-16 15:11:17 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2015:2039 0 normal SHIPPED_LIVE new packages: devtoolset-4-gdb 2015-11-16 20:08:41 UTC

Description Frank Hirtz 2015-09-13 03:17:19 UTC
Description of problem:

"gstack" is a generic script that's packaged in all of our gdb releases, but since we don't set the environmental variable for GDB, we'll always just default to "/usr/bin/gdb" regardless of whether you're using DTS or not. We should probably correct that.

Version-Release number of selected component (if applicable):
devtoolset-3-gdb-7.8.2-38.el6.x86_64

Additional info:

There are 2 ways to address this that I see. Either we set the GDB environmental variable by default as part of the scl enable script, or we modify the "gstack" script to be a bit smarter about it's default. Something like:

-GDB=${GDB:-/usr/bin/gdb}
+GDB=${GDB:-`which gdb`}

So, we'd just use whichever gdb was in our path first unless the dev sets their $GDB variable to point somewhere else. Either would work, though the second seems a bit more robust.

Comment 1 Jan Kratochvil 2015-09-13 05:35:15 UTC
I find it is just enough to put there:
GDB=${GDB:-gdb}

Comment 2 Jan Kratochvil 2015-09-13 06:00:34 UTC
/usr/bin/gdb-add-index is using:
GDB=${GDB:=gdb}


/usr/bin/gcore has a large block starting with:
# Attempt to fetch the absolute path to the gcore script that was
# called.
binary_path=`dirname "$0"`

That probably tries to mimick so-called 'relocatable' file access by GDB which is turned off in Fedora/RHEL releases:
perl -i.relocatable -pe 's/^(D\[".*_RELOCATABLE"\]=" )1(")$/${1}0$2/' gdb/config.status
! grep '_RELOCATABLE.*1' gdb/config.h

Comment 3 Jan Kratochvil 2015-09-13 18:40:24 UTC
I have put the
  GDB=${GDB:-gdb}
fix into Rawhide:
  http://pkgs.fedoraproject.org/cgit/gdb.git/commit/?id=44ca5e4d1ecf75b72eb123787c5cf2f5085f1188

Comment 4 Jan Kratochvil 2015-09-14 13:32:59 UTC
The same bug affects also gcore:

+ . /opt/rh/devtoolset-4/root/usr/bin/gcore 30632
++ '[' 1 -eq 0 ']'
++ name=core
++ '[' 30632 = -o ']'
+++ dirname bash
++ binary_path=.
++ test x. = x.
+++ basename bash
++ binary_basename=bash
++ test -f bash
+++ alias
+++ /usr/bin/which --tty-only --read-alias --show-dot --show-tilde bash
++ binary_path_from_env=/usr/bin/bash
+++ dirname /usr/bin/bash
++ binary_path=/usr/bin
++ '[' '!' -f /usr/bin/gdb ']'
++ rc=0
++ for pid in '$*'
++ /usr/bin/gdb --nx --batch -ex 'set pagination off' -ex 'set height 0' -ex 'set width 0' -ex 'attach 30632' -ex 'gcore core.30632' -ex detach -ex quit

Comment 5 Jan Kratochvil 2015-09-14 15:03:32 UTC
Comment 4 was a wrong test, gcore is OK:

+ '[' 1 -eq 0 ']'
+ name=core
+ '[' 31011 = -o ']'
++ dirname /opt/rh/devtoolset-4/root/usr/bin/gcore
+ binary_path=/opt/rh/devtoolset-4/root/usr/bin
+ test x/opt/rh/devtoolset-4/root/usr/bin = x.
+ '[' '!' -f /opt/rh/devtoolset-4/root/usr/bin/gdb ']'
+ rc=0
+ for pid in '$*'
+ /opt/rh/devtoolset-4/root/usr/bin/gdb --nx --batch -ex 'set pagination off' -ex 'set height 0' -ex 'set width 0' -ex 'attach 31011' -ex 'gcore core.31011' -ex detach -ex quit

Comment 9 errata-xmlrpc 2015-11-16 15:11:17 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2015-2039.html


Note You need to log in before you can comment on or make changes to this bug.