The explanation here is just a matter of trying it out as a premise. You shouldn't expect to get useful information from a chopped, incomplete core file. If you try a little and it doesn't work, you can save time by giving up and thinking about getting the core file correctly next time.
I used the core file used in java core: HotSpot compiler crashed on SIGSEGV as the original material.
The original core file has a size of about 240M bytes, but try cutting it to about 200M bytes as follows.
$ dd if=./core.15045 of=./core.x bs=1024k count=200
200+0 record input
200+0 record output
209715200 bytes(210 MB)Copied, 4.11797 seconds, 50.9 MB/Seconds
$ ls -l core.15045 core.x
-rw-r--r--1 root root 240611328 April 23 11:51 core.15045
-rw-r--r--1 imai imai 209715200 April 25 18:37 core.x
$
$ objdump -a ./core.x
objdump:warning: ./core.x is truncated:Expected core file size>=240611328. Found size: 209715200。
./core.x:File format elf64-x86-64
./core.x
If you look at this chopped core file with gdb, the stack information etc. will not be displayed correctly.
$ gdb /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.141-2.6.10.5.el7.x86_64/jre-abrt/bin/java ./core.x
...Omission...
Core was generated by `java -classpath /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomca'.
Program terminated with signal 6, Aborted.
#0 0x00007f50747b01f7 in ?? ()
(gdb) bt
#0 0x00007f50747b01f7 in ?? ()
#1 0x00007f50747b18e8 in ?? ()
#2 0x0000000000000020 in ?? ()
#3 0x0000000000000000 in ?? ()
(gdb)
(gdb) info shared
Cannot access memory at address 0x7f507538f128
Cannot access memory at address 0x7f507538f120
No shared libraries loaded at this time.
(gdb)
Manually set information about what library is mapped to which address so that you can check it with gdb. First, use the readelf command to find a rough map address from the note section of the core file. You can then determine which address to map by adding the start address of the .text section of the shared library to that address.
$ readelf -n ./core.x
...Omission...
0x00007f507477a000 0x00007f507477b000 0x0000000000000015
/usr/lib64/libz.so.1.2.7
0x00007f507477b000 0x00007f5074933000 0x0000000000000000
/usr/lib64/libc-2.17.so
0x00007f5074933000 0x00007f5074b33000 0x00000000000001b8
/usr/lib64/libc-2.17.so
0x00007f5074b33000 0x00007f5074b37000 0x00000000000001b8
/usr/lib64/libc-2.17.so
...
$ readelf -S /usr/lib64/libc-2.17.so | grep text
[12] .text PROGBITS 000000000001f480 0001f480
$
Of the above, it was displayed first/usr/lib/64/libc-2.18.Confirmed with the start address of so and readelf.Add the start position of text to find the address.
(gdb) p/x 0x00007f507477b000 + 0x000000000001f480
$1 = 0x7f507479a480
(gdb)
To this address, libc-2.17.Map so.
(gdb) add-symbol-file /usr/lib64/libc-2.17.so 0x7f507479a480
add symbol table from file "/usr/lib64/libc-2.17.so" at
.text_addr = 0x7f507479a480
(y or n) y
Reading symbols from /usr/lib64/libc-2.17.so...(no debugging symbols found)...done.
Missing separate debuginfos, use: debuginfo-install glibc-2.17-196.el7.x86_64
(gdb)
Calculate the addresses and map each shared library as described above. If it is java core, the main libraries are libc, libpthread, libjvm, so after mapping those three, check the stack information with gdb again.
(gdb) add-symbol-file /usr/lib64/libc-2.17.so 0x7f507479a480
(gdb) add-symbol-file /usr/lib64/libpthread-2.17.so 0x7f5074f55900
(gdb) add-symbol-file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.141-2.6.10.5.el7.x86_64/jre/lib/amd64/server/libjvm.so 0x7f507390b110
(gdb)
libc, libpthread,After mapping libjvm, let's check the stack with bt.
(gdb) bt
#0 0x00007f50747b01f7 in raise ()
#1 0x00007f50747b18e8 in abort ()
#2 0x00007f5073f18de9 in os::abort (dump_core=<optimized out>) at /usr/src/debug/java-1.7.0-openjdk-1.7.0.141-2.6.10.5.el7.x86_64/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:1635
#3 0x00007f50740a7bcf in VMError::report_and_die (this=this@entry=0x7f5070c49bd0)
at /usr/src/debug/java-1.7.0-openjdk-1.7.0.141-2.6.10.5.el7.x86_64/openjdk/hotspot/src/share/vm/utilities/vmError.cpp:1074
#4 0x00007f5073f21ff7 in JVM_handle_linux_signal (sig=11, info=0x7f5070c49e30, ucVoid=0x7f5070c49d00, abort_if_unrecognized=<optimized out>)
at /usr/src/debug/java-1.7.0-openjdk-1.7.0.141-2.6.10.5.el7.x86_64/openjdk/hotspot/src/os_cpu/linux_x86/vm/os_linux_x86.cpp:531
#5 <signal handler called>
#6 0x00007f5073f646c0 in Phase::Phase (this=0x0, pnum=Phase::Compiler)
at /usr/src/debug/java-1.7.0-openjdk-1.7.0.141-2.6.10.5.el7.x86_64/openjdk/hotspot/src/share/vm/opto/phase.cpp:83
#7 0x00007f5073b78711 in Compile::Compile (this=0x0, ci_env=0x7f5070c4ba40, compiler=0x7f506c072730, target=0x7f503c0ba4f0, osr_bci=-1, subsume_loads=<optimized out>,
do_escape_analysis=true, eliminate_boxing=true) at /usr/src/debug/java-1.7.0-openjdk-1.7.0.141-2.6.10.5.el7.x86_64/openjdk/hotspot/src/share/vm/opto/compile.cpp:683
#8 0x00007f5073ae3d30 in C2Compiler::compile_method (this=0x7f506c072730, env=0x7f5070c4ba40, target=0x7f503c0ba4f0, entry_bci=-1)
at /usr/src/debug/java-1.7.0-openjdk-1.7.0.141-2.6.10.5.el7.x86_64/openjdk/hotspot/src/share/vm/opto/c2compiler.cpp:137
#9 0x00007f5073b7f788 in CompileBroker::invoke_compiler_on_method (task=task@entry=0x7f506c1595c0)
at /usr/src/debug/java-1.7.0-openjdk-1.7.0.141-2.6.10.5.el7.x86_64/openjdk/hotspot/src/share/vm/compiler/compileBroker.cpp:1761
#10 0x00007f5073b80b00 in CompileBroker::compiler_thread_loop ()
at /usr/src/debug/java-1.7.0-openjdk-1.7.0.141-2.6.10.5.el7.x86_64/openjdk/hotspot/src/share/vm/compiler/compileBroker.cpp:1597
#11 0x00007f5074059cfa in JavaThread::thread_main_inner (this=this@entry=0x7f506c0a8800)
at /usr/src/debug/java-1.7.0-openjdk-1.7.0.141-2.6.10.5.el7.x86_64/openjdk/hotspot/src/share/vm/runtime/thread.cpp:1687
#12 0x00007f507405a07f in JavaThread::run (this=0x7f506c0a8800) at /usr/src/debug/java-1.7.0-openjdk-1.7.0.141-2.6.10.5.el7.x86_64/openjdk/hotspot/src/share/vm/runtime/thread.cpp:1667
#13 0x00007f5073f17de2 in java_start (thread=0x7f506c0a8800) at /usr/src/debug/java-1.7.0-openjdk-1.7.0.141-2.6.10.5.el7.x86_64/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:910
#14 0x00007f5074f57e25 in start_thread ()
#15 0x00007f507487334d in clone ()
(gdb)
In this way, even a truncated core file can provide information.
Recommended Posts