Compiled a C++ program using gcc -pg -g (at least, those are the args I gave in the Makefile; don't have any hard evidence of what command was executed). Program ran to normal completion with CWD set to my home directory. No gmon.out file written.
gcc is 4.4.7. OS is centos 6.
My program was launched by a hand-rolled Perl daemon using fork/exec. I've verified that the CWD is my home directory, and that it's writeable, by having the daemon execute touch foo just before exec'ing my target program. As far as I've been able to research, this shouldn't have affected the program's profiling or writing gmon.out when it terminated (normally).
Ran into this same issue, g++ 4.8.2 on CentOS 7. -pg was present for both compiling and linking, run the process & it exits normally, no gmon.out generated.
I fixed this by replacing a call to _exit(status) with exit(status). Note that the former is _exit(3), a system call, and the latter is exit(2), a standard library method.
Why does this work? From the gprof man page:
The profiled program must call "exit"(2) or return normally for the profiling information to be saved in the gmon.out file.
Apparently the writing of gmon.out is dependent on (the higher-level) exit(2). So, check to be sure the code is using exit(2) (from stdlib) and not _exit(3) (system call).
This is really late, but for those of you who are struggling, after you compile your code with -pg, you need to run the executable for it to generate gmon.out
Maybe you have solved this months ago but I encountered the effect today so I can answer for future visitors:
No error message is shown, gmon.out just does not get created (and the analysis text-file will be empty).
One reason why this might be is if you have no main method or in the case of -mwindows a WinMain. E.g. if you use the compiler arguments (gcc) -e or (vc) /entry or using __main.
I looked over the gprof manual but did not find info about how to tell it an entry point so I changed the code.
In my case, the issue was that the executable was chdir'ing (changing the current working directory) to elsewhere, and that's where gmon.out ended up.
I ran my program with strace to see system calls and could see that it was writing the gmon output at the end of the trace.
Related
For some time I didn't compile/run my programs using g++ in cmd and I only used CodeBlocks where I didn't have any problems so I don't know when this started.
So I tried to run a program that I compiled with 'g++ main.cpp' and it either wouldn't run at all, like nothing happened, or this would pop out.
From a not so related answer in google I found that adding the -static-libstdc++ flag would fix this but I don't want to do this every time and the OCD in me wants to know why this is happening.
P.s. As mentioned in the title this only happens when the program has the string type in it. I also tried reinstalling Mingw but no luck.
As #n. 'pronouns' m instructed in the comments, I checked my %PATH% and found LyX, a Latex document processor which I don't even remember using, which for some reason also had the libstdc++-6.dll file. I uninstalled it and that fixed it.
I have this project that I've been doing. On WSL, when I compile, there seem to be no issues. Everything works well and good.
However, I need the compiled code in a .exe format so I can run it on windows and call it within a Python code.
I have installed flex, bison and MinGW (from mysys2) and all of them have been added to my path/environment variables.
I have ran command prompt as Admin as well to avoid any permissions issues that may have come up.
In this image, flex command works without hitches and produces the lex.yy.c file as expected. However, g++/gcc command does not show any error. Neither does it produce the .exe file
Over here, I have compiled with -ll appended to the statement, and once again the same result.
Note: It took significantly longer to compiler with -ll appended than without. Not sure if this is significant information.
I found a thread(g++ does not make any file or give any output) where someone addressed the same problem but there was no proper solution that has worked.
Does anyone know a solution or what the problem could be? Any help would be appreciated.
I have a c++ executable file named test .. To execute it in my terminal I run.....
./test
Although I want to run it in debug mode wherein it shows the exact command being used immediately after being executed
If you are wondering what exactly I mean by debug mode..
Just like how we use -x for shell scripts
sh -x test.sh
OR
bash -x test.sh
This shows every command immediately after its executed .
I want same thing for this test c++ executable file.
I hope there would be some way.
To debug a c++ program you need to:
1. Compile the program with debug information.
You need to tell the compiler to include information about symbols in the executable to be able to debug it later (at least to debug it in an easy way). For example if you use g++, add the -g option)
2. Run the program with attached debugger
Since your question is tagged with linux, you may want to use gdb. There also exist tools that provide a gui.
You cannot execute C++ source files. You have to first compile them into executables. Then you run the executable. C++ is not an interpreted scripting language.
I'm working on a project, where I cannot disclose the details of the code. So, the application is all written in C and C++. Since, a particular file which wanted to debug has a lot of dependencies and exports, I need to debug the whole project. How do I set breakpoints in the code itself so that the debugging would stop at that particular point? I'm using Ubuntu 14.04 (since the project is compatible with this environment) and gdb debugger.
I've tried using
#include <csignal>
// Generate an interrupt
std::raise(SIGINT);
But I keep getting error
error: ‘raise’ is not a member of ‘std’
Even this also didn't work
#include <signal.h>
raise(SIGINT);
Plus the debugging wont stop at that point, so that I could foresee the function at that point. I only want to debug it from console, rather using any IDE.
Since the programfile I want to debug has lot many header files which it imports, I'm unable to make a executable to use gdb. So, while make clean build of my MakeFile I want to debug the particular program file at a particular function. So, for that I want to add breakpoints in the program. I cannot use any GUI for debugging since I should not use.
Have you tried to use GDB Commands?
b lineno - set a break point at line 'lineno'
b srcfile:lineno - set a break point in source file 'srcfile' at line 'lineno'
Read more about debugging with gdb. Be sure to compile all your code with DWARF debug information (so use g++ -Wall -Wextra -g to compile it with GCC).
GDB is extensible and you can define your own gdb commands at startup in your init file, probably .gdbinit and put some initial commands there.
BTW, on Linux, debugging (so the gdb debugger) is using ptrace(2) facilities. And you can use gdb non-interactively on the command line, using scripts.
How do I set breakpoints in the code itself
I don't recommend adding specific C code for breakpoints. So don't do that in your C code. But see also this.
Perhaps you want some backtrace library, like Ian Taylor's libbacktrace ?
I cannot use any GUI for debugging
You don't need to. You'll use gdb on the command line. With an appropriate gdb script, you can even use it non-interactively (e.g. in a Makefile)
I only want to debug it from console, rather using any IDE.
Please realize that IDEs are only glorified source code editors capable of running other external tools (including the GCC compiler and the gdb debugger). You certainly don't need -on Linux- any IDE to run a compiler or a debugger (but IDEs could be convenient, but not necessary, for that), because you can (and should) run your compiler, your debugger, your build automation tool, on the command line.
Since the program file I want to debug has lot many header files which it imports, I'm unable to make a executable
You should fix that first. You need to make an executable. BTW, there is no "import" involved at run time, since header files are relevant only at compile time. Read more about the cpp preprocessor. You probably should invoke GCC (e.g. the g++ compiler, since you have C++ code) with appropriate preprocessor options (sometimes, tools like pkg-config are useful for that). You probably should use some build automation tool such as GNU make (with your Makefile; see this for inspiration) or ninja. You could add ad hoc gdb commands to your build procedure (e.g. with some additional and specific rules and/or recipes in your Makefile).
First, make sure you have compiled with -g. There are other gdb specific flags in gcc. You could add them in too.
Try using ddd, the graphical version of gdb. Great tool if you don't know the gdb command line. Just open up the relevant source file, select the line then click on breakpoint on the toolbar. It will tell you on the console section, what command was actually executed (good way to learn). There is a floating button list with run, next etc. for stepping through your code.
ddd will work on most of the gcc toolchain.
EDIT:
Say your code is made up of 2 files main.cpp and child.cpp. main.cpp contains main(). The executable is called a.out.
To start
ddd a.out &
It will open in main.cpp. To put a breakpoint in child.cpp, click on File/Open Source... and select child.cpp. Then scroll to where you want a breakpoint. Put your cursor on the line, then click on break in the toolbar.
To run, either type run in the gdb window below or click on Run in the floating button dialog.
What are the 'best practices' when it comes to debugging core dumps using GDB?
Currently, I am facing a problem:
The release version of my application is compiled without the '-g' compiler flag.
The debug version of my application (compiled with '-g') is archived (along with the source code, and a copy of the release binary).
Recently, when a user gave me a core dump, I tried debugging it using
gdb --core=./core.pid ./my_app_debug-bin
The core was created by my_app_release-bin. There seems to be some kind of mismatch between the core file and the binary.
On the other hand, if I try
gdb --core=./core.pid ./my_app_release-bin
the core matches but I am unable to get source code line numbers (although I get the function names).
Is this what is practised? Because I feel I am missing something here.
It sounds like there are other differences between your release and debug build then simply the absence/presence of the -g flag. Assuming that's the case, there is nothing you can do right now, but you can adjust your build to handle this better:
Here's what we do at my place of work.
Include the -g flag when building the release version.
Archive that version.
run strip --strip-unneeded on the binary before shipping it to customers.
Now, when we get a crash we can use the archived version with symbols to do debugging.
One thing to note is that if your release version includes optimization, debugging may be difficult even with symbols. For example, the optimizer can reorder your code so even though the debugger will say you crashed on line N, you can't assume that the code actually executed line N-1.
You need to do some additional stuff to create binaries with stripped debug information that you can then debug from cores. Best description I could find is here
No, you don't miss anything. debug and release are just different binaries, so the core files of release don't match the debug binary. You have to look at machine code to get something from the release core dump.
You probably have to ask your user how the crash happened and collect additional log information or whatever you app produces.