Hide Forgot
Description of problem: I am using SSH to access a DIY application and cannot debug programs with gdb. How reproducible: Always Steps to Reproduce: 1. ssh <id@foo-bar.rhcloud.com> 2. gdb /bin/ls 3. run Actual results: GNU gdb (GDB) Red Hat Enterprise Linux (7.2-50.el6) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /bin/ls...error: cannot open Packages database in error: cannot open Packages database in error: cannot open Packages database in error: cannot open Packages database in error: cannot open Packages database in error: cannot open Packages database in Missing separate debuginfo for /bin/ls Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/2e/9ba41f5b576688e607d8b7a25d7aa4c390f661.debug (no debugging symbols found)...done. (gdb) run Starting program: /bin/ls error: cannot open Packages database in error: cannot open Packages database in error: cannot open Packages database in error: cannot open Packages database in Missing separate debuginfo for /lib64/ld-linux-x86-64.so.2 Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/ce/b82e745b0ab8bb7ea28c068327be1fb068c923.debug Detaching after fork from child process 8366. Detaching after fork from child process 8368. Detaching after fork from child process 8370. Welcome to OpenShift shell This shell will assist you in managing OpenShift applications. !!! IMPORTANT !!! IMPORTANT !!! IMPORTANT !!! Shell access is quite powerful and it is possible for you to accidentally damage your application. Proceed with care! If worse comes to worst, destroy your application with 'rhc app destroy' and recreate it !!! IMPORTANT !!! IMPORTANT !!! IMPORTANT !!! Type "help" for more info. [golang-violet.rhcloud.com ~]\> exit Program exited normally. (gdb) quit Expected results: GDB starts /bin/ls, not the shell.
Interesting request. We'll have to look at this in a few phases. 1) Is this something safe for us to allow? (Security related) 2) How do we actually do this? (Would we have to install debug packages for lots of stuff?) 3) Is this something we want to offer by default in the hosted product. We'll get started on 1 right now.
1) You are already allowing gdb to attach to a running process (gdb --pid N).
Workaround would be to just set the SHELL variable before you invoke gdb. (export SHELL=/bin/bash) -- that should make it work.
I put in a fix to master earlier last week -- SHELL is now set to bash instead of trap-user and this works now (you can run /bin/ls via gdb or run :!ls from within vi). Until the fix is released to prod, use the above mentioned workaround.
Verified on devenv_2242 Steps: 1. Create a diy app and ssh into it 2. Check what SHELL it is using 3. gdb /bin/ls Result: [diy1-2242t.dev.rhcloud.com ~]\> echo $SHELL /bin/bash [diy1-2242t.dev.rhcloud.com ~]\> gdb /bin/ls GNU gdb (GDB) Red Hat Enterprise Linux (7.2-56.el6) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... .............. (gdb) run Starting program: /bin/ls [Thread debugging using libthread_db enabled] app-root diy-0.1 diy1 git Program exited normally.