coredump

How to reliably take JVM core dump if application is in GC?

由 本秂侑毒 提交于 2019-12-06 07:03:28
问题 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

Why LD_PRELOAD doesn't work for one of loaded shared libraries?

由 亡梦爱人 提交于 2019-12-06 05:26:25
问题 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

After the Ruby interpreter segfaults, is it possible to get the Ruby backtrace from the corefile?

由 爷，独闯天下 提交于 2019-12-06 03:31:24
问题 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

Restoring program state from a core file

由 早过忘川 提交于 2019-12-05 16:23:14
问题 Is it possible, under any circumstances, to restore the state of a program to what it was during the generation of a core file? The reason I ask is that in order to take advantage of gdb's ability to execute functions and so forth you need to have a running instance. Surely it should be possible to produce a mock process of the same executable with the state set to be the contents of the core? If not what alternatives are there for the sort of situation that made me want to do this in the

what is the reason for core dump? stack shows from oracle lib

由 女生的网名这么多〃 提交于 2019-12-05 16:00:52
I have a coredmp where all thread stack look normal but one stack shows like this. Can any one tell me possible reason for this? i can see exit is being called from oracle libs, is this issue of oracle? Can any one guide me when this can happen? Thread 3 (process 26454): #0 0x00002b803ceb54a8 in exit () from /lib64/libc.so.6 #1 0x00002b803bbe93f5 in skgdbgcra () from /home/oracle/product/11g/lib/libclntsh.so.11.1 #2 0x00002b803be9cdec in kpeDbgCrash () from /home/oracle/product/11g/lib/libclntsh.so.11.1 #3 0x00002b803be9c627 in kpeDbgSignalHandler () from /home/oracle/product/11g/lib/libclntsh

Is it possible to debug core file generated by a executable compiled without gdb flag?

由 折月煮酒 提交于 2019-12-05 03:32:53
Is it possible to debug core file generated by a executable compiled without gdb flag ? If yes, any pointers or tutorials on it ? snap Yes you can. It will not be easy though. I will give you an example. Lets say that I have the following program called foo.c : main() { *((char *) 0) = '\0'; } I'll compile it and make sure that there is no symbols: $ cc foo.c $ strip a.out $ file a.out a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped Ok, time to run it: $ ./a.out Segmentation fault (core dumped) Oops. There

Why does scikit-learn cause core dumped?

由 。_饼干妹妹 提交于 2019-12-05 02:08:29
I try to run a simple linear fit in scikit-learn: from sklearn import linear_model clf = linear_model.LinearRegression() clf.fit ([[0, 0], [1, 1], [2, 2]], [0, 1, 2]) As a result I get: Illegal instruction (core dumped) Does anybody know what is the reason of this problem and how the problem can be resolved? P.S. I use the version 0.16.1 of scikit-learn. But I had this problem also with an older version. I do it under Ubuntu. ADDED Today I have tried another estimator ( KernelRidge ) and I got the same error message. I think that several month ago I tried to solve a system of linear equations

infinite abort() in a backrace of a c++ program core dump

由 跟風遠走 提交于 2019-12-05 01:41:57
I have a strange problem that I can't solve. Please help! The program is a multithreaded c++ application that runs on ARM Linux machine. Recently I began testing it for the long runs and sometimes it crashes after 1-2 days like so: *** glibc detected ** /root/client/my_program: free(): invalid pointer: 0x002a9408 *** When I open core dump I see that the main thread it seems has a corrupt stack: all I can see is infinite abort() calls. GNU gdb (GDB) 7.3 ... This GDB was configured as "--host=i686 --target=arm-linux". [New LWP 706] [New LWP 700] [New LWP 702] [New LWP 703] [New LWP 704] [New LWP

Is a core dump executable by itself?

由 拥有回忆 提交于 2019-12-04 22:10:36
问题 The Wikipedia page on Core dump says In Unix-like systems, core dumps generally use the standard executable image-format: a.out in older versions of Unix, ELF in modern Linux, System V, Solaris, and BSD systems, Mach-O in OS X, etc. Does this mean a core dump is executable by itself? If not, why not? Edit: Since @WumpusQ.Wumbley mentions a coredump_filter in a comment, perhaps the above question should be: can a core dump be produced such that it is executable by itself? 回答1: In older unix

Force a core to dump from an active, normally running program on FreeBSD

由 你。 提交于 2019-12-04 15:15:14
问题 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? 回答1: kill -QUIT process_id will cause a core dump from a
订阅 coredump