coredump

问题 What is a core dump file in linux? What all information does it provide? 回答1: 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.

问题 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

问题 I want to create a core dump whenever my process crashes. Currently I am following this approach: Build a special "debug" version of the program using "-g" of gcc/g++. Execute "ulimit -c unlimited" Now we get the core dump whenever the program crashes. But I want to minimize the number of steps so that: Core dump should always get created. Even if it is "release" build. The user should not be asked to execute the command " ulimit -c unlimited " manually. That core dump's backtrace should be

问题 Similar points to the one in this question have been raised before here and here, and I'm aware of the Google coredump library (which I've appraised and found lacking, though I might try and work on that if I understand the problem better). I want to obtain a core dump of a running Linux process without interrupting the process. The natural approach is to say: if (!fork()) { abort(); } Since the forked process gets a fixed snapshot copy of the original process's memory, I should get a

问题 My production system occasionally exhibits a memory leak I have not been able to reproduce in a development environment. I've used a Python memory profiler (specifically, Heapy) with some success in the development environment, but it can't help me with things I can't reproduce, and I'm reluctant to instrument our production system with Heapy because it takes a while to do its thing and its threaded remote interface does not work well in our server. What I think I want is a way to dump a

问题 I need a way to request a heap dump from within the application . Rationale: When I encounter a specific error condition, I'd like to dump heap, so that I can see what is holding on to the memory. But I would like to automate this (For example, when I detect that some specific condition has occurred. Or when a watchdog doesn't gets its pings anymore. When some test fails). Thus I need a way to dump the heap from within the application itself. I can't seem to find it with the MX beans stuff.

问题 Sometimes when I run my code, a core dump file is generated when I terminate the program by Ctrl + \ . The file name is of the form core.* . The program is not terminating abruptly, and there is no segmentation fault. I believe it is SIGQUIT and not SIGABRT or SIGSEGV . If I try Ctrl + C , or Ctrl + Z , then it is not generated. Can anyone tell why it is generated only when Ctrl + \ is pressed? How can I avoid this core dump file from being generated? Is there any use for the core dumped file

问题 What is SEGV_MAPERR , why does it always come up with SIGSEGV ? 回答1: 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 the address space of the application at all. This will often result from dereferencing a null pointer or a pointer that was

问题 My implementation of strcat(char*, const char*) seems to work but then it causes a core dump. strcat() implementation: char* strcat(char* dest, const char* src) { char* tmp = dest; while(*tmp) ++tmp ; while( (*tmp++ = *src++ ) != '\0') ; return (dest); } Code in int main() where I call strcat(): char arr3[] = "Mr. "; char arr4[] = "Smith"; printf("Hello %s!", strcat(arr3, arr4)); It actually concatenated both strings and printed it out but still caused a core dump. output : Hello Mr. Smith

问题 While running a C program, It says "(core dumped)" but I can't see any files under the current path. I have set and verified the ulimit : ulimit -c unlimited ulimit -a I also tried to find a file named "core", but didn't get the core dumped file? Any help, where is my core file? 回答1: Read /usr/src/linux/Documentation/sysctl/kernel.txt. [/proc/sys/kernel/]core_pattern is used to specify a core dumpfile pattern name. If the first character of the pattern is a '|', the kernel will treat the rest