I'm using the latest version of dbxtool (Solaris Studio ) on RHEL6.1.
I'm working through the tutorial example here using their example code, but when trying to run dbxtool on the core file generated, I get the following:
(dbx) cd /users/rory/Desktop/debug_tutorial
(dbx) debug /users/rory/Desktop/debug_tutorial/a.out core.a.out.10665
Reading a.out
dbx: warning: The corefile was truncated.
It should have been 1765376 bytes long (is only 483328)
Because of this, some functionality will be missing from dbx.
(See `help core')
core file header read successfully
Reading ld-linux-x86-64.so.2
Reading libstdc++.so.6
Reading libm.so.6
Reading libgcc_s.so.1
Reading libc.so.6
program terminated by signal SEGV (Segmentation fault)
dbx: core file read error: address 0x3faff579bc not available
dbx: attempt to fetch registers failed - stack corrupted
The first warning is about the core file being truncated (should have been 1765376 bytes long (is only 483328)), but I am able to generate other core files in the same directory with a larger size, so not sure why this one is being truncated?
I've also gone through the tutorial here on removing core size file limits, but with no luck.
This is a known dbx problem on RH6 (CR 7077948). The core file size is miscalculated if a data segment has a memory size larger than the file size (p_filesz) in the elf header. This problem has been identified and fixed in dbx 7.9.
Related
I'm currently running a file manager program that abruptly crashed with a segmentation fault and dumped a core file. So I used gdb to debug the core file as:
gdb /path/to/executable /path/to/core
The program which I was running is written in C++. When I ran GDB and tried to print the source lines using "list", I got the following error:
(gdb) bt
#0 0x0000000000554286 in
MyFSEventManager::AddEvent(wxFileSystemWatcherEvent&) ()
#1 0x00000000005ab2e8 in
MyGenericDirCtrl::OnFileWatcherEvent(wxFileSystemWatcherEvent&) ()
(gdb) f 0
#0 0x0000000000554286 in
MyFSEventManager::AddEvent(wxFileSystemWatcherEvent&) ()
(gdb) l
1 /build/glib2.0-prJhLS/glib2.0-2.48.2/./glib/gmain.c: No such file or directory.
Why does gdb say this "/build/glib2.0-prJhLS/glib2.0-2.48.2/./glib/gmain.c: No such file or directory." I do not hit this issue with some other programs that I've debugged using gdb.
The operating system used is Ubuntu 16.04 running on Oracle virtual box. I think may be the gdb symbols were not loaded. I'm not sure why since I compiled the program using the "-g" option. I really need to know the source lines where the code crashes via gdb.
Any suggestions?
EDIT: changes after suggestions from Employed Russian
I was compiling my main using "-g" option and linking it to "existing" object files which were obviously not compiled using "-g" so when the core dumped, I could not see the source for these files. So I went ahead and recompiled those files with "-g" option and reproduced the core dump. It's able to show me the source lines now.
Why does gdb say this "/build/glib2.0-prJhLS/glib2.0-2.48.2/./glib/gmain.c: No such file or directory."
Because you really don't have that file on your system.
I think may be the gdb symbols were not loaded
GDB did load debug symbols for glib, but not for your main executable.
I'm not sure why since I compiled the program using the "-g" option.
Since we don't have your compile and link lines, we can't tell exactly what's wrong, but some of the common issues are:
You have a "stray" -s or -Wl,-s on your link line (this strips debug info from the resulting binary).
You have -g when compiling your main.c, but not when compiling the source in which MyFSEventManager::AddEvent() is defined
P.S.
(gdb) bt
This doesn't seem to be the complete output from bt command. Always try to paste complete outputs as it makes helping easier :)
The core dump files generated when my app crashes seem systematically short of about 2692 bytes, when loading them in gdb I get :
BFD: Warning: [...]core is truncated: expected core file size >= 117628928, found: 117626236.
Sizes vary a bit but the missing part (difference between the expected size and what's found) is always between 2690 and 2693 bytes.
Before starting the app I force :
ulimit -c unlimited
There's plenty of space and time for the system to write the file.
Other details that may be relevant :
- The target is an APF27.
- It runs Linux kernel 2.6.38
- The core file is generated on a SD card.
- The size of the file matches the size found by gdb.
Any hint will be appreciated.
reWhen analyzing a core file, my gdb 7.0 outputs several warnings:
warning: Wrong size gregset in core file.
warning: Wrong size fpregset in core file.
warning: Wrong size gregset in core file.
warning: Wrong size fpregset in core file.
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
I am not sure if its related, but I am unable to get a backtrace:
(gdb) bt
#0 0x00000000 in ?? ()
OS architecture is SUN Solaris 10 SPARC.
Questions:
What is the reason/cause of these warnings?
Why can't I retrieve a backtrace?
How to fix these problems?
The problem can in gdb as well in your program.
I would recommend to update gdb to the most recent version (7.3.1). Also it could be helpful to create simple test program and analyze its core with gdb to be sure that your utility works fine.
"gregset" and other error indicate that gdb unable read the data from the core file. It can happen if your program gone wild and corrupt stack. gregset error means that gdb was unable to read general-purpose register set from a core file. fpregset is for floating-point register set. The expected register size is platform dependent.
bt would not work if you cant read core file properly.
I also had the fpregset warnings (and no stack trace) when I tried to work on a 64bit core dump with gdb 7.6.2 on Solaris 10. The cause seems to be, that the userspace applications of Solaris 10 are compiled with 32bits by default - and without support for 64bit core cumps.
The guys in GDB's IRC channel gave me the following parameter:
--enable-64-bit-bfd
I also compiled a 64bit version of gdb (-m64), but that shouldn't be necessary. Now gdb could work on the 64bit core dump and create the stack trace without any warnings.
"Bus Error" doesn't tell me much so I want to access the core file to find out where it went wrong. I try to do this:
(gdb) core core
/this/is/my/directory/Program/core: No such file or directory
(gdb)
but it says there is no directory. I compile my program using Qt on mac and it does not produce anything called 'core'. Any advice on how to debug this?
Thank you.
I don't use a Mac, but it seems like core files are either suppressed by default or written to a dedicated directory. You could copy the core file to your program directory and invoke gdb with the excecutable and core file name:
Where are core dumps written in Mac OS X?
GDB: http://www.gnu.org/software/gdb/documentation/
gdb <program_name> <core_file_name>
I have just moved from Ubuntu 10.04 to the new version of 11.04 and when I try to debug with ddd/gdb I cannot set anymore breakpoints nor see the flow while the debugger is executing my program.
I receive error messages saying
(gdb)b MyFile.cpp:27
No line 27 in file "MyFile.cpp".
When I start running my application calling r I also can see the following text message that looks to me related to my issue. The debuggers traps all assertions but I cannot stop at any point.
(gdb) r
BFD: /lib/x86_64-linux-gnu/libc.so.6: invalid relocation type 37
BFD: BFD (GNU Binutils) 2.18.50.20080226 assertion fail elf64-x86-64.c:278
BFD: /lib/x86_64-linux-gnu/libc.so.6: invalid relocation type 37
BFD: BFD (GNU Binutils) 2.18.50.20080226 assertion fail elf64-x86-64.c:278
If I want to see the file, the debuggers open the file with me but I receive the following error message
(gdb) list MyFile.cpp:27
Line number 27 is out of range for "MyFile.cpp".
Can you help me?
I read some forum asking to check the result of info source and info sources and this is what I have but I don't know what to do with it.
(gdb) list MyFile.cpp:27
Line number 27 is out of range for "MyFile.cpp".
(gdb) info source
Current source file is /usr/local/include/boost/exception/exception.hpp
Compilation directory is /home/emanueler/trunk/tools/myAppBinary
Located in /usr/local/include/boost/exception/exception.hpp
Contains 436 lines.
Source language is c++.
Compiled with unknown debugging format.
Includes preprocessor macro info.
Why it says "Compiled with unknown debugging format." when I am giving the -g option at compiler?
It seems all the compiling related tools were also updated, including GCC. It would be best if you recompile your entire application in this new environment before trying to debug it again.
You can do a simple test for check that your toolchain is ok. Write a small hello world app, compile it with -g and try to set a breakpoint on the cout line.