Trying out DDD for the first time in conjunction with some C++ code I already have written and compiled on another machine. When I run DD with the code, I get this error:
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
terminate called after throwing an instance of 'std::runtime_error'
what(): User configuration file not found
Program received signal SIGABRT, Aborted.
0x00007ffff6f84428 in __GT_raise (sig=sig#entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 (gdb)
Not sure what to think, as I have the code built and running on an RPi. Any help would be most appreciated!
When I run DD with the code, I get this error
That is an error from your program (which throws exception).
You can find out where that error is coming from using the GDB where command.
If your program doesn't throw this exception when you run it outside of DDD, it's likely that your program looks for "configuration file" in its current directory (bad idea (TM)), and that the directory in which you start it is different from the directory in which DDD starts it.
You can use cd command inside DDD to change the current directory, and this will likely "fix it" for you (but really you should fix your program so that it uses $HOME or some other well defined location for its configuration files).
Related
Why is gdb showing that the program exited during its startup, so before to stop at the first breakpoint in the main function ?
Some steps:
$ gdb --cd $programhome -tui -tty $reservedtty --args myprogram
b main
r
gdb shows:
Starting program: myprogram
During startup program exited with code 1.
I already tried to break at exit() function, without success.
Why is gdb exiting before to stop at the first breakpoint in the main function
GDB is not exiting. Your program does.
It does exit before reaching main.
This can happen for a few reasons, such as:
Corrupt binary -- the kernel rejects it in execve system call for some reason and not a single instruction of the program actually runs.
The dynamic linker rejects it (e.g. because some required library or symbol is missing)
Your shell refuses to execute the program (bad ~/.bashrc, bad $PATH, etc).
You can narrow down the actual cause by running the program outside GDB (does it run?), running without ~/.bashrc, using (gdb) catch syscall exit_group (on Linux), etc.
There was a permission issue accessing the secondary terminal port.
The gdb is being started with the parameter -tty which switches the input/output to another tty port (in that case pseudo: pts).
When the two terminals are opened by different users, that problem occurs, even if after the first logon you change the user with su command, the first user logged needed to be the same among the two ttys.
I'm having a problem debugging a command line program on OS X. I've used this same source file with the same g++ command line hundreds of times to test things with the Crypto++ library.
Under GDB, I get the following after loading the EXE:
$ gdb ./cryptopp-test.exe
...
(gdb) r
Starting program: /Users/jwalton/cryptopp-test.exe
Unable to find Mach task port for process-id 42811: (os/kern) failure (0x5).
Under LLDB, I get the following:
$ lldb ./cryptopp-test.exe
Current executable set to './cryptopp-test.exe' (x86_64).
(lldb) r
error: initial process state wasn't stopped: exited
I've recompiled the program a few times, and I can't get it to run under a debugger. I'm getting a segfault when trying to run outside the debugger too, so that may be a symptom here also.
OS X is 10.8.5, and Xcode is 5.1.1 (5B1008). Everything is fully patched. The only thing to change recently is signing up for a developer account, which is broken thanks to Apple's DRM crap. I can't seem to get any of it to work with Xcode or the command line even though Roots and Certificates are in my Keychain. But this program does not use code signing.
What is causing the initial process state wasn't stopped: exited error, and how do I fix it?
The errors that you have received are usually a direct correlation of a codesigning issue, not with your executable, but with gdb and lldb themselves.
You have a couple of options:
Launch gdb or lldb as sudo (which ignores the codesign req to run executables)
Create a codesigning certificate for gdb or lldb in Keychain.app
Obviously the first option is quickest, but probably should be avoided as it opens up the possibility of bad things happening with elevated permissions.
With option #2 you can likely get gdb or lldb properly working by doing this:
Launch /Applications/Utilities/Keychain Access.app
Select the Keychain Access -> Certificate Assistant -> Create a Certificate...
Choose a name for the new certificate (for example lldb-cert or gdb-cert)
Set Identity Type to Self Signed Root
Set Certificate Type to Code Signing
Select the Let me override defaults option
Continue until the "Specify a Location For The Certificate" screen appears
Set Keychain to System and Continue
In the view showing your certificates, double-click on the one just created and then set "When using this certificate" to "Always Trust"
In Terminal:
codesign -f -s "gdb-cert" /path/to/gdb (or) "lldb-cert" /path/to/lldb
You might have to restart for this to effectively take hold.
There are more concise instructions here for gdb and here for lldb on the codesigning process.
How can I redirect execution errors of a c++ executable in bash? I've found that 2> helps while trying identify compilation errors:
g++ example.cpp 2> compErr.txt
But running the executable with that command still sends the errors to stdout:
$ ./a.out 2> e.txt
Floating point exception (core dumped)
Actually, the error "Floating point exception (core dumped)" does not come from the executable but from the shell! The messages from bash won't be suppressed by output redirection but there is a flag to enable/disable these messages.
You can install signal handlers for some of the errors which would cause the program to exit and write something to a suitable destination there. Some signals can't be intercepted and some other are hard to handle. That's the approach you can do from inside your code.
If you want to go further you could fork() your program first thing and have the actual work done in the child process. The parent process would essentially just waitpid() for the child process and use the information in the result structure received to report errors to a file.
I found something that worked in my terminal, here: http://bytes.com/topic/c/answers/822874-runtime-error-stderr-gcc-ubuntu-bash
In summary, a participant explained:
In this particular case, the reason that the string "Floating point exception" is not >redirected is that it is not produced by the process that runs ./{file} or anything that it invokes. Instead,it is being produced by the command-interpreter itself.
You can see this by telling the command interpreter to run another command interpreter, redirecting this sub-interpreter's error output. However, a bit of a >trick is required:
$ bash -c './{file}; true' >out 2>err
$ cat out
$ cat err
bash: line 1: 28106 Floating point exception./test_fail
Is there anyway to debug a link error or any kind of error that may occur before the execution of the main() function using GDB?
Is there anyway to debug a link error
Presumably you are asking about runtime link error (e.g. `error: libfoo.so: no such file or directory'), and not about (static) link step of your build process.
The trick is to set a breakpoint on exit or (exit_group on Linux) system call with e.g. catch syscall exit. You will then be stopped inside ld.so at the point where it gives up running your binary.
or any kind of error that may occur before the execution of the main() function using GDB?
Any other kind of error, e.g. SIGSEGV can be debugged "normally" -- for signal you don't need to do anything at all -- GDB will just stop. For other errors, just set a breakpoint as usual.
On way to debug initialization code (even if you don't have symbols) goes like this:
gdb somebinary
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
etc.
info file
Symbols from "somebinary".
Local exec file:
`/somebinary', file type elf64-x86-64.
Entry point: 0x4045a4, etc.
break *0x4045a4
run
...Breakpoint 1, 0x00000000004045a4 in ?? ()
From here on you can proceed as usual.
I have a large C++ function which uses OpenCV library and running on Windows with cygwin g++ compiler. At the end it gives Aborted(core dumped) but the function runs completely before that. I have also tried to put the print statement in the end of the function. That also gets printed. So I think there is no logical bug in code which will generate the fault.
Please explain.
I am also using assert statements.But the aborted error is not due to assert statement. It does not say that assertion failed. It comes at end only without any message.
Also the file is a part of a large project so I cannot post the code also.
gdb results:
Program received signal SIGABRT, Aborted.
0x7c90e514 in ntdll!LdrAccessResource () from /c/WINDOWS/system32/ntdll.dll
It looks like a memory fault (write to freed memory, double-free, stack overflow,...). When the code can be compiled and run under Linux you can use valgrind to see if there are memory issues. Also you can try to disable parts of the application until the problem disappears, to get a clue where the error happens. But this method can also give false positives, since memory related bugs can cause modules to fail which are not the cause of the error. Also you can run the program in gdb. But also here the position the debugger points to may not be the position where the error happened.
You don't give us much to go on. However, this looks like you are running into some problem when freeing resources. Maybe a heap corruption. Have you tried running it under gdb and then looking where it crashes? Also, check if all your new/delete calls match.
Load the core dump together with the binary into gdb to get an idea at which location the problem list. Command line is:
gdb <path to the binary> <path to the core file>
For more details on gdb see GDB: The GNU Project Debugger.
Run it through AppVerifier and cdb.
E.g.
cdb -xd sov -xd av -xd ch <program> <args>