0

I am facing a specific challenge while debugging with GDB. My binary is generating core. When i am debugging it GDB. I am not getting relevant debugging information.

GDB stack trace (bt):-

[root@ussdgw5 bin]# gdb pull core.11328
GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-23.el5)
Copyright (C) 2009 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 "i386-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/abc/xyz/bin/pull...done.
[New Thread 11379]
[New Thread 11378]
[New Thread 11377]
[New Thread 11376]
Reading symbols from /lib/libpthread.so.0...(no debugging symbols found)...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /opt/septel/lib32/libgctlib.so.1...(no debugging symbols found)...done.
Loaded symbols for /opt/septel/lib32/libgctlib.so.1
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_files.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_files.so.2
Core was generated by `./pull -c /home/abc/xyz/conf/Common.cfg -g /home/abc/xyz/'.
Program terminated with signal 11, Segmentation fault.
#0  0x2e6e6f69 in ?? ()
(gdb) bt
#0  0x2e6e6f69 in ?? ()
#1  0x40310738 in ?? ()
#2  0x20459102 in menu_table ()
#3  0x31073900 in ?? ()
#4  0x35910240 in ?? ()
#5  0x01530084 in ?? ()
#6  0x00000052 in ?? ()
#7  0x00000000 in ?? ()
(gdb) q

bt and bt full is not showing any useful info. I have complied my binary -g flag. The same binary had generated normal core (core with proper debugging info) that had i have fixed.

In this particular case i am not able to identify any issue. Please suggest how i can debug and resolve the issue.

user2307143
  • 1
  • 2

2 Answers2

1

Below pointers may help you to check the debugging info -
1. Check if you have compiled your code with debugging info on. (like -g and optimization flag off -O(2/3/4/5)) etc.
2. Check during the core generation - you have sufficient space in your system. A truncated core file will not have complete details to check for symbols.
3. Check if the debugging environment is exactly same as the run environment (in case both are at different location). An incorrect environment also can lead to unknown symbols.

These are some pointer. If I recall some more, I will update the answer. HTH!

kumar_m_kiran
  • 3,982
  • 4
  • 47
  • 72
  • @user2307143: Did it help you? What was the actual problem? If you drop in the actual problem and solution (and may be up-vote relevant answer) it would help other members scrolling for similar issues. – kumar_m_kiran Apr 23 '13 at 04:31
  • No.I have used -g flag while compiling. I have not used -O at all. I have also cross checked, space was sufficient. My development and production environments are same. Initially from your comment i though space could be the issue.But its not. I am not able to find the solution. The code access the same function many a times but some how it generated segmentation fault after 3-4 day and core has not relevant info except menu_table function. – user2307143 Apr 23 '13 at 04:58
0

gdb pull core.11328

Core was generated by ./ussd_pull_gw ...`

The most likely cause of your troubles is a binary mis-match: you are probably analyzing core that was produced by a different executable.

You need to use the exact same executable that produced the core. Rebuilding the executable with e.g. -g instead of -O2 would lead to the results you observed (but rebuilding with -g -O2 often works).

Community
  • 1
  • 1
Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • Thanks. Now I have used the correct binary. But still the result is same. Debugging environment & development environment are same.The same binary used to generate proper core. I have fixed those issues but now its generating with no debugging info. – user2307143 Apr 23 '13 at 04:26
  • @user2307143 "debugging and development environment are same" -- does that mean you are recording the core dump and analyzing it on the same machine? "but now its generating with no debugging info" -- please update your question; I doubt you are getting the *exact* same output you were getting before. – Employed Russian Apr 23 '13 at 04:32
  • Yes. I have enabled the -g flag on the production machine and compiling the code in the same machine. "No debugging info" means its generating debugging info that is not sufficient for debugging as you see in the trace attached above. I can just see menu_table function and then some hex addresses. Please suggest what could be the issue. – user2307143 Apr 23 '13 at 05:37