Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 630
  • Last Modified:

How to debug shared objects?

Hello,
I just started using gdb and am having trouble debugging with shared
objects. If I do a 'bt' and gdb shows the following,
--------
......
(gdb) bt
Program received signal SIGINT, Interrupt.
[Switching to Thread 1087287744 (LWP 24850)]
0xffffe410 in ?? ()
Current language:  auto; currently c
(gdb) bt
#0  0xffffe410 in ?? ()
#1  0xbffff47c in ?? ()
#2  0xffffffff in ?? ()
#3  0x00000001 in ?? ()
#4  0x40a02e94 in poll () from /lib/tls/libc.so.6
#5  0x40a329c5 in svc_run () from /lib/tls/libc.so.6
#6  0x08053d79 in core_server () at sxmrpc_svc.cpp:452
#7  0x0804e3d2 in main (argc=1, argv=0xbffff734) at main.cpp:159
(gdb)
--------
I can do a 'frame 4', and then what should I do in order to step into
the source code of libc.so.6 to see which line the app was at in
poll()?
Thanks for any help.
0
minjiezen
Asked:
minjiezen
  • 4
  • 3
  • 2
  • +1
1 Solution
 
ahoffmannCommented:
step
0
 
minjiezenAuthor Commented:
I did that but I got the following error:
----------
Cannot find bounds of current function
----------
I also did a 'list' (after I did a 'frame 4') and it lists the lines around main.cpp line 159, which is in frame 7. Looks like gdb cannot see the source code for the shared library. How do I make gdb see the source code of a shared library?

0
 
ahoffmannCommented:
path /path/to/source/


help
help files
:-)
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
minjiezenAuthor Commented:
It still does not work. I made up a hang situation in a shared library (say, mylib.so) of my own as follows (note: mylib.so was built from several source files in C++):
    {
        int i = 1;
        for (i=0; i < 1000000000; i++)
            usleep(1000*1000);
     }
And I ran the application as follows:
gdb myapp
The app hung when it reached the above code (because of the loop). So I do the following:
(gdb) Ctrl-c  (my input, to go back to the gdb prompt)
Program received signal SIGINT, Interrupt.
[Switching to Thread 1087287744 (LWP 5077)]
0xffffe410 in ?? ()
Current language:  auto; currently c
(gdb) bt   (my input)
#0  0xffffe410 in ?? ()
#1  0xbffff2c8 in ?? ()
#2  0x40d8ee0c in __JCR_LIST__ () from /usr/lib/mylib.so
(gdb)
It does not show in which file and in which line the application is hung. I set up the source path for the file that has that loop implemented, but gdb cannot find it. The purpose of this test is to try to mimic the real situation where the application is hung and I need to find out in which file and in which line the application got into trouble.
Any info will be greatly appreciated.
 
0
 
ahoffmannCommented:
> It does not show in which file and in which line the application is hung.
then gdb is not configured proper with path to the source
see man gdb, or info gdb how to use path command
0
 
minjiezenAuthor Commented:
I tried to set path in gdb as follows:
path /path/to/source
and
directory /directory/to/souce
But neither worked. And these two are the only commands to set directory or path in gdb, according to the gdb documents. I also tried 'info line *address', etc., but gdb just couldn't figure out which line and program it was at.
Is there another way to get gdb prompt once the program hangs? Looks like gdb has all the info about the source code (yes, it could see the file that contained the almost-infinite loop implementation), UNTIL I used Ctrl-c command to go to the gdb prompt. It's as if Ctrl-c erased all gdb's rememberance of the application it had before.
0
 
Duncan RoeSoftware DeveloperCommented:
You can set breakpoints in shared libraries. Does your gdb let you set a breakpoint on the usleep line? (Of course, the code must have been compiled with -g and not subsequently stripped).
As for seeing source lines in glibc - unless gdb complains that it can't find the source files, your library was not built with -g. Build it from the SRPM with -g turned on (man rpmbuild).
If you have trouble setting a breakpoint inside your own shared lib, we should attack that problem first.
0
 
minjiezenAuthor Commented:
Hello duncan roe, thanks for your reply. Yes, I can set up a breakpoint in my shared library (on the usleep line), in which case GDB tells me the source info (file name and line number). The problem is that in the real situation, when our application hangs, I would not know where (in which file) it is hung because that shared library is built from quite a few .cpp and .h files, so there is no way for me to set a breakpoint beforehand because I don't know where the problem is. I would like to get the source info after the application has hung, but that's when GDB does not give me any source info except the shared library name (after I use Ctrl-c to get the GDB prompt again).
0
 
Duncan RoeSoftware DeveloperCommented:
I can't imagine what is going wrong here. I'bve never had that sort of trouble with gdb myself.
Anyway, there is another way. Gdb your program, set a breakpoint at main. 'n'ext through the mainline until you get to the line that hangs ('n' doesn't comeback with a pronmpt).
Gdb the program again, but this time breakpoint at the "hanging" line. When you get there, do a 's'tep. Then 'n'ext through the called function until you get to the hanging line of *that* function.
Gdb the program again, but this time breakpoint at the "hanging" line you just found. And so on...
Sounds tedious but should get you there fairly quickly. You can use 'u'ntil to get you past loops that don't seem to be the priblem. Good Luck...
0
 
rahul_miloCommented:
One suggestion:
Try compiling whole of your code with -ggdb option...
It adds extra information in object code during compilation.
And then try to debug.
0

Featured Post

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

  • 4
  • 3
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now