coredump

What is a core dump file in linux? What all information does it provide? It's basically the process address space in use (from the mm_struct structure which contains all the virtual memory areas), and any other supporting information *a , at the time it crashed. For example, let's say you try to dereference a NULL pointer and receive a SEGV signal, causing you to exit. As part of that process, the operating system tries to write your information to a file for later post-mortem analysis. You can load the core file into a debugger along with the executable file (for symbols and other debugging

I have a few questions: Why was a.out replaced by ELF ? What were the major flaws in the a.out format that led to the raise of ELF file format? Earlier core dumps were based on a.out, but now they are based on ELF. What are the various advantages provided by ELF? The a.out format forced shared libraries to occupy a fixed place in memory. If you wanted to distribute an a.out shared library, you had to register its address space. This was good for performance but it didn't scale at all. See for yourself how tricky it was (linuxjournal). By contrast, in ELF, shared libraries can be loaded

My application is mostly Java but, for certain calculations, uses a C++ library. Our environment is Java 1.6 running on RedHat 3 (soon to be RedHat 5). My problem is that the C++ library is not thread-safe. To work around this, we run multiple, single-threaded "worker" processes and give them work to do from a central Work Manager, also written in C++. Our Java application calls the C++ Work Manager via a third-party product. For various reasons, we want to re-write the C++ Work Manager and workers. I'm in favour of writing them all in Java, using JNI in each worker to call the C++ library.

I am looking for a way to select the sections and memory regions included in a core dump. My application's core dump size is about 30GB, most of it is in preallocated buffers which I don't even need in debugging (and can be zeroed later). However, since the dump is so big, it takes too much time for the application to finish crashing and begin recovery. Can anyone think of a way to select in advance which segments will be in the core dump? Thanks According to the core(5) manpage, you can set which mappings are written to the core file: Since kernel 2.6.23, the Linux-specific /proc/PID/coredump

If I use gcore to make a code dump of a Node.js process, what are the best tools to analyze it? Inspired by: Tool for analyzing java core dump In my specific case, I'm interested in investigating some memory leaks, so I'm really curious to get some heap analysis. General tools and even instrumentation packages and techniques are also welcome. I'm finding Node.js to be very interesting, but the runtime analysis tools are just not there yet. For investigating crashes, I've found node-segfault-handler to be invaluable. It's a module I cooked up to get a native-code stack trace in the event of a

I want to change the default location of core dump files so that every time a core dump is generated ,it goes to that directory.Also, is it possible to save the dump file by the name of the crashed file in this location? mata Yes, it is. You can change /proc/sys/kernel/core_pattern to define the pathname used to generate the corefile. For more, see man core example: echo '/tmp/core_%e.%p' | sudo tee /proc/sys/kernel/core_pattern # `tee' instead of > so that # opening happens in the # elevated process would cause all future core dumps to be generated in /tmp and be named core_[program].[pid]