Sponsored Content
Top Forums Programming Best guide or video for gdb <register level debugging> Post 302929083 by Corona688 on Wednesday 17th of December 2014 02:04:46 PM
Old 12-17-2014
You debug "stack faults" by seeing what's happening before the fault. It's difficult to make sense of the stack fault itself, for the same reason a museum is more useful before it burns down.

Register information isn't too useful without knowing what's in those registers. That's why gdb likes to have debugging information -- to tell it how to get variables, not just random cryptic registers.

An example using gdb debugging a crash fault:

Code:
$ cat gdb.c

#include <stdio.h>
#include <string.h>

int main(void) {
        char *strings[]={"a","B"}; // What happens when we forget to make element 3 NULL?
        char buf[64];
        int n;

        for(n=0; strings[n] != NULL; n++)
        {
                char *val=strings[n];
                strcpy(buf, "123:");
                strcat(buf, val);
                printf("%s\n", buf);
        }
}

$ gcc -ggdb gdb.c

$ ./a.out

123:a
123:B
123:B
Segmentation fault

$ gdb ./a.out

# It's not running yet.  Set a breakpoint so it doesn't run, crash,
# and quit before we can see anything.
(gdb) break main
Breakpoint 1 at 0x400592: file gdb.c, line 5.

(gdb) run
Starting program: /home/tyler/code/c/1shot/a.out
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?

Breakpoint 1, main () at gdb.c:5
5               char *strings[]={"a","B"};
# Run it one step at a time, to see line numbers.
(gdb) step
9               for(n=0; strings[n] != NULL; n++)
(gdb) step
11                      char *val=strings[n];

# Let's stop at this line every loop.
(gdb) break gdb.c:11
Breakpoint 2 at 0x4005ab: file gdb.c, line 11.

# What registers the relevant values are in can vary.
# That's why gdb needs debugging info -- so you can ask it for
# VARIABLES.
(gdb) print strings[n]
$1 = 0x4006a4 "a"

# That looks ok.  That won't crash.  Let it run.
(gdb) continue
Continuing.
123:a

Breakpoint 2, main () at gdb.c:11
11                      char *val=strings[n];
(gdb) print strings[n]
$2 = 0x4006a6 "B"

# Still OK.
(gdb) continue
Continuing.
123:B

Breakpoint 2, main () at gdb.c:11
11                      char *val=strings[n];
(gdb) print strings[n]
$3 = 0x4006a6 "B"

# Um.  The array has two elements, but this is the third loop?
# This value "looks ok" but is actually garbage.
# You cannot tell this without knowing the program of course...
(gdb) continue
Continuing.
123:B

Breakpoint 2, main () at gdb.c:11
11                      char *val=strings[n];
(gdb) print strings[n]

# We are now two elements beyond the end of the array.
# The first just "happened" to work by coincidence, but THIS WILL
# crash, and this is why:
$4 = 0x300000000 <error: Cannot access memory at address 0x300000000>
(gdb) continue
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7ab6360 in ?? () from /lib64/libc.so.6
(gdb) quit
A debugging session is active.

        Inferior 1 [process 9589] will be killed.

Quit anyway? (y or n) y

$

Debugging a crash without finding the context around it isn't too useful, you have to see what happens BEFORE the crash.
 

7 More Discussions You Might Find Interesting

1. Programming

Debugging 64bit code with gdb and ddd in AIX

I'm trying to use the GDB debugger and DDD to debug 64bit code. It seems that the AIX toolkit gdb version 6.0 works with 64bit code. But the ddd tool when running gdb gives the following errors : Starting program: <my binary> <my params> warning: "": not in executable format: There is an input... (2 Replies)
Discussion started by: bean66
2 Replies

2. Programming

Debugging a running process in GDB

Hi , Any gdb user could see my problem. Let me describe what i want to do. i have a test utility to send message to running process. My interest is to go through to functions calls when my test case starts. In a simple way i want have a code walk for a particular scenario of a test... (1 Reply)
Discussion started by: meet123321
1 Replies

3. Solaris

Difference between run level & init level

what are the major Difference Between run level & init level (2 Replies)
Discussion started by: rajaramrnb
2 Replies

4. Red Hat

SSL certificate generation on OS level or application level

We have a RHEL 5.8 server at the production level and we have a Java application on this server. I know of the SSL certificate generation at the OS (RHEL) level but it is implemented on the Java application by our development team using the Java keytool. My doubt is that is the SSL generation can... (3 Replies)
Discussion started by: RHCE
3 Replies

5. UNIX for Dummies Questions & Answers

GDB Debugging Problem

I have added some code in my file. I have created executable rpm file of our code and also I have created debuginfo and debugsource files and installed all three. But when I debug in gdb I see the the code changes in soucre file. But the break point does not hit at that place as if it did not... (1 Reply)
Discussion started by: rupeshkp728
1 Replies

6. Red Hat

Gdb error while debugging core file

Hi, I am trying to analyze one core file on my RHEL 6.5, but I am getting below error related to the core file. So I am not getting any stack trace about the crash. # gdb MyDebugBin /var/core/MyDebugBin.27005 GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6_4.1) Copyright (C) 2010 Free... (2 Replies)
Discussion started by: sanzee007
2 Replies

7. Programming

64 bit code debugging using gdb and ddd

Hello I have built our application on AIX 7.1 as a 64 bit application. My queries are as follows: Can a 32bit gdb (v7.6) and ddd (data display debugger - v3.3.12), debug a 64bit executable ? If I have a small 64bit a.exe executable that seems to work. If I have a more complicated executable... (4 Replies)
Discussion started by: biju64
4 Replies
GZEXE(1)						      General Commands Manual							  GZEXE(1)

NAME
gzexe - compress executable files in place SYNOPSIS
gzexe name ... DESCRIPTION
The gzexe utility allows you to compress executables in place and have them automatically uncompress and execute when you run them (at a penalty in performance). For example if you execute ``gzexe /usr/bin/gdb'' it will create the following two files: -rwxr-xr-x 1 root root 1026675 Jun 7 13:53 /usr/bin/gdb -rwxr-xr-x 1 root root 2304524 May 30 13:02 /usr/bin/gdb~ /usr/bin/gdb~ is the original file and /usr/bin/gdb is the self-uncompressing executable file. You can remove /usr/bin/gdb~ once you are sure that /usr/bin/gdb works properly. This utility is most useful on systems with very small disks. OPTIONS
-d Decompress the given executables instead of compressing them. SEE ALSO
gzip(1), znew(1), zmore(1), zcmp(1), zforce(1) CAVEATS
The compressed executable is a shell script. This may create some security holes. In particular, the compressed executable relies on the PATH environment variable to find gzip and some standard utilities (basename, chmod, ln, mkdir, mktemp, rm, sleep, and tail). BUGS
gzexe attempts to retain the original file attributes on the compressed executable, but you may have to fix them manually in some cases, using chmod or chown. GZEXE(1)
All times are GMT -4. The time now is 11:11 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy