Using Python’s gc garbage collector interface and sys.getsizeof() it’s possible to dump all the python objects and their sizes. Here’s the code I’m using in production to troubleshoot a memory leak: rss = psutil.Process(os.getpid()).get_memory_info().rss # Dump variables if using more than 100MB of memory if rss > 100 * 1024 * 1024: memory_dump() os.abort() def … Read more
$ gdb –pid=26426 (gdb) gcore Saved corefile core.26426 (gdb) detach
This link contains a good checklist why core dumps are not generated: The core would have been larger than the current limit. You don’t have the necessary permissions to dump core (directory and file). Notice that core dumps are placed in the dumping process’ current directory which could be different from the parent process. Verify … Read more
It seems they are suppressed by default. Running $ ulimit -c unlimited Will enable core dumps for the current terminal, and it will be placed in /cores as core.PID. When you open a new session, it will be set to the default value again.
You can resolve this in several ways: Use g++ in stead of gcc: g++ -g -o MatSim MatSim.cpp Add -lstdc++: gcc -g -o MatSim MatSim.cpp -lstdc++ Replace <string.h> by <string> This is a linker problem, not a compiler issue. The same problem is covered in the question iostream linker error – it explains what is … Read more
Raising of signal number 6 (SIGABRT in Linux) is one way to do it (though keep in mind that SIGABRT is not required to be 6 in all POSIX implementations so you may want to use the SIGABRT value itself if this is anything other than quick’n’dirty debug code). #include <signal.h> : : : raise … Read more
There are two common kinds of SEGV, which is an error that results from an invalid memory access: A page was accessed which had the wrong permissions. E.g., it was read-only but your code tried to write to it. This will be reported as SEGV_ACCERR. A page was accessed that is not even mapped into … Read more
You can use the core with GDB in many ways, but passing parameters which is to be passed to the executable to GDB is not the way to use the core file. This could also be the reason you got that error. You can use the core file in the following ways: gdb <executable> <core-file> … Read more
This depends on what shell you are using. If you are using bash, then the ulimit command controls several settings relating to program execution, such as whether you should dump core. If you type ulimit -c unlimited then that will tell bash that its programs can dump cores of any size. You can specify a … Read more
You just need a binary (with debugging symbols included) that is identical to the one that generated the core dump file. Then you can run gdb path/to/the/binary path/to/the/core/dump/file to debug it. When it starts up, you can use bt (for backtrace) to get a stack trace from the time of the crash. In the backtrace, … Read more