Hello Daisuke, The test dump can be found here: http://people.redhat.com/anderson/.gcore_test_dump One important thing to note -- the dumpfile was taken with the "snap.so" extension module while running live. It selects the "crash" process that was doing the live dump as the panic task. So when you do a backtrace on it, it looks like this: crash> bt PID: 2080 TASK: ffff880079ed2480 CPU: 0 COMMAND: "crash" #0 [ffff88007a615b08] schedule at ffffffff81480533 #1 [ffff88007a615bf0] rcu_read_unlock at ffffffff811edfd3 #2 [ffff88007a615c00] avc_has_perm_noaudit at ffffffff811eea76 #3 [ffff88007a615c90] avc_has_perm at ffffffff811eeae3 #4 [ffff88007a615d10] inode_has_perm at ffffffff811f2815 #5 [ffff88007a615de8] might_fault at ffffffff810f22ec #6 [ffff88007a615e80] might_fault at ffffffff810f2335 #7 [ffff88007a615eb0] crash_read at ffffffffa004f103 [crash] #8 [ffff88007a615f00] vfs_read at ffffffff8112115b #9 [ffff88007a615f40] sys_read at ffffffff81121278 #10 [ffff88007a615f80] system_call_fastpath at ffffffff81009c72 RIP: 000000333a0d41b0 RSP: 00007fffac23a7f0 RFLAGS: 00000206 RAX: 0000000000000000 RBX: ffffffff81009c72 RCX: 0000000000000000 RDX: 0000000000001000 RSI: 0000000000ca5440 RDI: 0000000000000004 RBP: 0000000000000004 R8: 000000007a615000 R9: 0000000000000006 R10: 00000000fffffff8 R11: 0000000000000246 R12: 0000000000ca5440 R13: 0000000000001000 R14: 0000000000001000 R15: 000000007a615000 ORIG_RAX: 0000000000000000 CS: 0033 SS: 002b crash> Now, when using "snap.so" to create a dumpfile, all of the "active" backtraces are not legitimate, because they were *running* when their kernel stacks were being read. So, for example, the "snap.so" code was running -- doing a read() -- when the "crash" stack was read. But since it had not panicked, there were no legitimate starting RIP/RSP values to use for starting points for the backtrace. So frame #'s 0 through #7 above should not be accepted as "real". But I presume that starting from frame #7 , would be correct.