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:
Debugging a crash without finding the context around it isn't too useful, you have to see what happens BEFORE the crash.
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)
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)
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)
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)
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)
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
LEARN ABOUT DEBIAN
gzexe
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)