Community:
I am trying to run gdb on a program that is crashing and I am getting messages of: +++ Missing separate debuginfos, use debug-install glibc-2.13.2.x86_64 libgcc-4.5.1.fc14.x86_64 libg++-4.5.1.fc14.x86_64 libstdc++-4.5.1.fc14.x86_64 ---
Googling is not giving me anything that I either understand or trust. Querying yum with -list isn't giving me any insight.
Is this message asking me to add something to the compile line or something to gdb? And, in either case, what is it asking for.
I'm hoping someone on this list has run into this debugging C++ and can clue me into where I need to look.
Thanks in advance, Paul
On 28/11/11 08:16, Paul Allen Newell wrote:
Community:
I am trying to run gdb on a program that is crashing and I am getting messages of: +++ Missing separate debuginfos, use debug-install glibc-2.13.2.x86_64 libgcc-4.5.1.fc14.x86_64 libg++-4.5.1.fc14.x86_64 libstdc++-4.5.1.fc14.x86_64
It's telling you to install the debug pkgs, which are not already installed. as the line says use "debug-install glibc-2.13.2.x86_64 etc..
On 11/28/2011 12:46 AM, Frank Murphy wrote:
It's telling you to install the debug pkgs, which are not already installed. as the line says use "debug-install glibc-2.13.2.x86_64 etc..
Frank:
Thanks for the reply. That is what I thought as well, but I couldn't see anything with yum -list. I am prepared to believe that I am blind to the obvious, but at this point I am still blind.
I don't have my F14 box online at the moment (I was thinking bed was the best immediate solution to the problem), but if you can confirm what I need to tell yum, I will fire the puppy up and test
Paul
On 28/11/11 08:50, Paul Allen Newell wrote:
I don't have my F14 box online at the moment (I was thinking bed was the best immediate solution to the problem), but if you can confirm what I need to tell yum, I will fire the puppy up and test
Paul
at the prompt ~$ debuginfo-install pkgname
Aside: With F14 eol in 2 weeks is it worth it? Maybe see if F15 has the same crash?
On 11/28/2011 1:09 AM, Frank Murphy wrote:
at the prompt ~$ debuginfo-install pkgname
Aside: With F14 eol in 2 weeks is it worth it? Maybe see if F15 has the same crash?
Frank:
Well, since I was looking for debuginfo-install as something yum would list, I would have never gotten close to the fact that debuginfo-install was a program in and of itself.
There is a part of me that wants to go "oh, I am just a newbie" but I have to admit there is a bigger part that says that I've been mucking in this code for "a very long time" and I think the messages in gdb aren't telling me what I need to do. Groan, that's just the way many things are.
As to the question of f14, I am kinda stuck at the moment as the Fedora world is happily (big smile) moving to f16 and I have to deal with Maya whose upcoming release is pegged to f14.
Really appreciate the quick turnaround on help on this one, now I just have to figure out what my program is doing which has caused me to ask these questions.
Paul
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/28/2011 04:16 PM, Paul Allen Newell wrote:
Community:
I am trying to run gdb on a program that is crashing and I am getting messages of: +++ Missing separate debuginfos, use debug-install glibc-2.13.2.x86_64 libgcc-4.5.1.fc14.x86_64 libg++-4.5.1.fc14.x86_64 libstdc++-4.5.1.fc14.x86_64
Googling is not giving me anything that I either understand or trust. Querying yum with -list isn't giving me any insight.
Is this message asking me to add something to the compile line or something to gdb? And, in either case, what is it asking for.
binaries and the associated debugging information (necessary for productively running gdb) are distributed as 2 separate rpms. foo and foo-debuginfo
The above message(s) are telling you (in so many words) that you need to install some debuginfo rpms, and in fact it is also telling you the command line to use to obtain those debuginfo rpms and install the,
specifically, the diagnostic is asking you to type the following:
debug-install glibc-2.13.2.x86_64 libgcc-4.5.1.fc14.x86_64 libg++-4.5.1.fc14.x86_64 libstdc++-4.5.1.fc14.x86_64
which will download and install the debuginfo rpms for glibc and the stdc++ librarys.
(this pre-supposes that you have standard yum setup, so that you will automatically find the debuginfo packages, which are not downloaded and installed by default).
This particular instance will, for example, allow you to step thru glibc (and/or stdc++) set breakpoints within the libraries, etc.
now. Having said that... It is not always absolutely necessary to install the library debuginfo's -- it all depends upon whether you are "ok" with not being able to step into, and set breakpoints in those libraries. i'm usually only interested in setting breakpoints in *my* code, for example, and usually do not install the debuginfo libraries for many of the associated libraries that my application links against. It's a judgement call.
If this is your first time, perhaps don't install the debuginfo for libraries where you think the problem isn't, and where you think you will not need to trace into said library(s). If, during debugging, you feel that "gee, it would be useful to set a breakpoint into that library, and see what's going on", then install the debuginfo for that library, and restart the debugger and your application.
All the best,
- -Greg
I'm hoping someone on this list has run into this debugging C++ and can clue me into where I need to look.
Thanks in advance, Paul
- -- +---------------------------------------------------------------------+
Please also check the log file at "/dev/null" for additional information. (from /var/log/Xorg.setup.log)
| Greg Hosler ghosler@redhat.com | +---------------------------------------------------------------------+
On Sat, Dec 3, 2011 at 08:12, Gregory Hosler ghosler@redhat.com wrote:
If this is your first time, perhaps don't install the debuginfo for libraries where you think the problem isn't, and where you think you will not need to trace into said library(s). If, during debugging, you feel that "gee, it would be useful to set a breakpoint into that library, and see what's going on", then install the debuginfo for that library, and restart the debugger and your application.
FWIW, stepping into libraries is not the only need. You might just want the symbols for those libraries for more information at debug time. To illustrate with an example:
libfoo.so might provide a class dummy and you maybe using it like
dummy myinstance; //.
Then having the libfoo-debuginfo package installed gives you the ability to do things like,
print myinstance.getattrib1()
or maybe even conditional breakpoints using these symbols.
-
Frank Murphy -
Gregory Hosler -
Paul Allen Newell -
Suvayu Ali