0

What is the reason for the core dump generated by J9 VM on linux platform, it just shows/contains only one thread (i.e current thread)?

Note: It is complete core dump(not truncated).

(gdb) info threads
* 1 Thread 0x7f33544d9700 (LWP 6471)  0x00007f335484d6e4 in j9dump_create () from ./app/was/IBM/WebSphere/AppServer/java/jre/lib/amd64/compressedrefs/libj9prt24.so
HRgiger
  • 2,750
  • 26
  • 37
Mohan Raj
  • 1,104
  • 9
  • 17
  • Are you referring to a core.*.dump file? Those are in a special format that can be read by tooling such as IBM Support Assistant. A javacore.*.txt file will usually be created at the same time, and the first few lines should have an explanation. – Brett Kail Jan 19 '16 at 15:04
  • In this question we are talking about core*.dmp and gdb cannot be used on javacore file. – Mohan Raj Jan 20 '16 at 03:49
  • I'm not sure what you're trying to say. Your question was "what is the reason for the core dump", and I explained that if javacore was generated at the same time, it should have the reason. AFAIK, gdb is not intended to be used on core.*.dmp files either. – Brett Kail Jan 20 '16 at 05:24
  • Question is about when core dump got generated by J9VM on linux platform and when it loaded by gdb and try to see all threads in the core dump but it shows only one thread? Here the question is why only one thread is shown in the coredump when it has multiple threads on it. Javacore will give the reason behind the core generation but here we are talking about core dump. – Mohan Raj Jan 20 '16 at 05:47
  • 1
    @BrettKail Regarding the comment that gdb is not intended to be used on core.*.dmp files, that's not true, it's a normal core dump and may be explored with gdb. See my answer to the question about why there's only a single thread if the core is produced using the IBM System Dump mechanism. – kgibm May 06 '16 at 22:16
  • 1
    @kgibm I stand corrected, thanks. (You might consider filling in your profile description.) – Brett Kail May 06 '16 at 23:21

1 Answers1

3

This is by design (in bold below):

Linux does not provide an operating system API for generating a system dump from a running process. The JVM produces system dumps on Linux by using the fork() API to start an identical process to the parent JVM process. The JVM then generates a SIGSEGV signal in the child process. The SIGSEGV signal causes Linux to create a system dump for the child process. The parent JVM processes and renames the system dump, as required, by the -Xdump options, and might add additional data into the dump file.

The system dump for the child process contains an exact copy of the memory areas used in the parent. The SDK dump viewer can obtain information about the Java threads, classes, and heap from the system dump. However, the dump viewer [gdb], and other system dump debuggers show only the single native thread that was running in the child process.

If you want all the threads, you may use gcore ${PID} or -Xdump:tool cleverly and execute gcore %pid.

IBM proposed a kernel API to create a core dump but it was rejected for security reasons (DoS). There is some experimentation with user-land core dumping.

kgibm
  • 852
  • 10
  • 22
  • 1
    http://stackoverflow.com/a/1074663/98959 describes why the rest of the native threads are gone in the forked process – covener May 07 '16 at 02:32