Computer And Technologies

Computer And Technologies: 11/09

Tuesday, 10 November 2009

Ho will you detect SNMP crash or core dump ?

How will you detect or how to debug where the core dump occures?
Please follow the steps:-

GDB is the GNU debugger, which is a terminal-based debugger. DDD is a graphical (GUI) front end to GDB.

Normal invocation

The simplest way to run an application under GDB is like so:

$ gdb /usr/local/sbin/snmpd
(gdb) run -f -Lo

The '-f' is necessary to prevent snmpd from forking into the background, and '-Lo' tells snmpd to send log messages to STDOUT (i.e. print them in the GDB console window).

Libtool invocation

Net-SNMP uses libtool while building it's applications. This means that sometimes the applications in the source/build directory are not actually binaries, but shell scripts. The libtool script does some magic so that the applications will run using the shared libraries in the build directory, instead of any libraries installed on the system. To run an application with GDB, you have to run GDB through libtool, like so:

$ ./libtool gdb agent/snmpd
(gdb) run -f -Lo

Getting a backtrace (aka stack trace)

Once you have got an application running under GDB, you can easily get a backtrace, which will display the sequence of functions that were called to arrive at the point where the debugger is currently stopped.

(gdb) bt
#0 0x10153d78 in init_snmp(type=0x101bb140 "snmp") at snmp_api.c:854
#1 0x1000524c in main(argc=3, argv=0x7fe04636) at snmpd.c:910
If an application has crashed, often it will leave a core file. This core file can usually be loaded into GDB to get debugging information after the fact. Simply add the path to the core file after the path to the application when starting GDB.
$ gdb /usr/local/sbin/snmpd /tmp/core.70816

Often this will tell you why the application crashed (e.g. SIGSEGV, aka signal 11). You can then get a backtrace to send to one of the mailing lists for interpretation.

If testing snmpd (or another application) from within the source tree, you'll need to run gdb via libtool:

$ ./libtool gdb agent/snmpd /tmp/core.70816

Debugger "DGB" Part-1

Introduction

This is a very short introduction into using gdb. Target audience is a unix user which has a serious problem with some application and wants to help fixing the issue by giving detailed informations to the developer or maintainer of the application.

Debug information

Unix binaries can have debug informations attached. gdb can use the debug informations to provide more detailed informations (like function prototypes, source file names and line numbers, ...), thus it is generally a good idea to use a binary which has debug informations.

gcc has a command line switch (-g) which will make gcc write debug informations into object files and executables. It is common practice in the free software community to compile projects with debug info, but strip it off when installing with "make install". Thus you'll usually see a big file size difference between the executables within the source tree and the installed ones, and using the executables from the source tree with gdb gives better results.

Analyzing a segfault

The linux kernel is able to write a so called core dump if some application crashes. This core dump records the state of the process at the time of the crash. gdb can read such a core dump and get informations out of it.

Most distributions have core dumps disabled by default, thus you'll have to reenable them first. "ulimit -c unlimited" will do that for the current shell and all processes started from it. Check the bash manpage if you want to know more about the ulimit command.

The next time some application crashes with a segfault you'll see that the message "Segmentation fault" changed to "Segmentation fault (core dumped)" and you'll find a file named "core" or "core.pid" in the current directory. Note: You need also write access for the current directory, otherwise that isn't going to happen.

Now it is time to start gdb to see what exactly happened. The first argument for gdb should be the executable of the crashed application, the second the core dump written due to the crash. gdb will read alot of informations and will great you with a "(gdb)" prompt when it is done. The most useful piece of information for a developer is a so called stacktrace. Typing "bt" at the prompt asks gdb to print one (which you can mail to the developer). With "quit" you'll leave gdb.

Other ways to use gdb

You can start a application completely under gdb's control. To do that just type "gdb executable". At the gdb prompt type "run arguments" to start the application. If the application receives some signal gdb will give you a prompt asking for commands. You can also type Ctrl-C at any time to get a gdb prompt. The most useful gdb commands are:

bt
print a stacktrace (as mentioned above).
c
continue running the application.
print expression
print the value of the specified expression. Can be used to inspect the value of certain variables for example, simply specify the variable name as expression
quit
quit gdb.

It is also possibel to attach gdb to a already running process. This can be done with "gdb executable pid". gdb will attach to the process specified by the process id. That might be useful it some application seems to be stuck in a endless loop and you want to figure where exactly it hangs.

Advanced gdb debugging

If you start to do more things with gdb than just printing a stacktrace you likely notice some odd effects like not being able to inspect certain variables. That may happen due to compiler optimizations. If gcc decides to make a variable a register variable (i.e. never store it somewhere in memory) gdb will not see it. To avoid that rebuild the application you are going to debug without optimizations.

More common gdb commands are:

s
single step though the application.
break argument
set breakpoints, i.e. make the application stop (and gdb give you a prompt) once it reaches some specific point, some function for example.
watch expression
set a watchpoint, i.e. stop if expression has changed. Can be used to catch the line of code which modifies some variable for example.
up, down
walk up and down in the stack, to inspect variables in other places of the stack too, not just the current function.
help
gdb online help. Go read there all the details, the scope of this document ends just here :-)
BTW: a nice info manual for gdb is available too.

other useful debug tools

electric fence
malloc debugger, helps to catch typical memory management bugs like accessing already freed memory, buffer overflows, ...
Comes as library which can either explicitly linked against the application or loaded via LD_PRELOAD.
strace
print a log of all (or selected) system calls some application performes.
One common programming mistake is missing error handling, not checking the return value of system calls for example. Instead of notifying the user with a message like "opening file foo failed with error bar" applications simply assume that opening the file worked and just crash later if it didn't. That kind of bug often can easily be found with strace because you'll see the system call return values in the strace log.
Of course strace is useful for alot of other purposes too.

Doubt in C programme

Dear all,

I have small doubt can anybody guide me how it's working and why?

It's give O/P as same code.
Please find the bellow code for your review.


int main()

{

char *s = "int main() { char *s = %c%s%c; printf(s,34, s, 34); ";

printf(s,34, s, 34);

}


Thanks,

-Amaresh

www.eOdissa.com