coredump

I'm trying to find the cause of memory leaks in my java application. I need to get a heap dump for a process that is in a long GC-cycle. Jmap isn't working in this case both because app is hanged and because heap is very large. Unfortunately, jmap throws UnknownOopException on the core dump I took. I suppose that it isn't correct to take core dump during GC. Is there any way to suspend java process at the point where taking core dump will be correct? Or am I totally wrong and got broken core dump because of some other problem? You cannot take a heap dump while a GC is being performed. You need

I have an in-house shared library on RedHat Linux 5.0 that provides functions free and malloc : >nm ./libmem_consumption.so | grep -P -e "\bfree\b|\bmalloc\b" 0000000000006540 T free 00000000000088a0 T malloc This shared library is responsible for providing information about memory consumption of a process. Unfortunatelly there is a problem with this shared library when it is used with Apache httpd . When Apache httpd is run with this library I get a coredump in libc::free and a message that the pointer is invalid. The problem seems to be in http.so which is a shared library loaded by libphp5

Note: I'm using a segfault that I encountered whilst using the libxml-ruby gem to illustrate the question, but I've since fixed my problem with said gem. What this question is really about is viewing the Ruby backtrace (i.e. the same thing the interpreter prints when Ruby code fails to handle an exception) from gdb with a corefile the interpreter itself encounters a segmentation fault. I'm getting an odd segfault while generating an XML document, of all things: /railsroot/vendor/isolated/ruby-1.8/gems/libxml-ruby-1.1.2/lib/libxml/node.rb:123: [BUG] Segmentation fault ruby 1.8.7 (2011-02-18

I am using Ubuntu 12.04 LTS. I wrote a simple program as follows to create crash // null.c #include<stdio.h> int main() { int *p = NULL; int k=*p; printf("%d",sizeof(0)); return 0; } Now I run with "gcc -g null.c" and then "./a.out" and the output is as expected. Segmentation fault (core dumped) Now I want to see the core dump file using gdb. I did the following things I checked the current directory, there is no core dump file I tried tried to change the /proc/sys/kernel/core_pattern with the content "core.%e.%p". But i am not able to write into the file. It is saying "Fsync Failed". I used

I know how to generate a core dump on OS X when a process crashes, but what I really need to do is attach to a process, generate a core dump, then resume that process (without killing it). A long time ago (maybe a year and a half ago) I had C code that would do this... It used the OS X kernel libraries to connect to a process, read all of its thread states and memory, and write that into a Mach-O file on disk. This worked great (and it's exactly what I'm looking for), but now I can't seem to find that code for the life of me. I seem to recall that code was related somewhat to the OS X system

I am getting a segmentation fault exactly at this line: while (fgets(line, MAX_LEN + 1, stream) != NULL) { .... } where MAX_LEN is 500, line is reading the current line, and stream is open through fopen(filename, "r"); I am reading lines from a file with a specific format and I get a segmentation fault (Core dumps) exactly at this line according to the debugger. I made my code so that it ignores lines that do not match the scanf format. Here is what I am implementing. Something close to it at least: int main(int argc, int **argv) { .... .... if (argc == 1) { printf("enter file name: "); scanf(

I'm writing error handling code for a server on FreeBSD. For extremely serious errors I want to avoid data corruption by immediately terminating. That's easy, exit(3) . Before I exit, I output my relevant variables that led me there. However, ideally, this termination would be accompanied by a .core so that I could fully investigate what got me to this catastrophic (and likely hard to reproduce) state. How can I force this to happen? kill -QUIT process_id will cause a core dump from a running process (assuming that resource limits allow it). Or see man 3 abort for causing a program to dump