Eugene,
Another debugging aid you can try already exists in the task-gathering
function refresh_hlist_task_table_v3(), which does this before
making the "duplicate task" check:
if (CRASHDEBUG(1)) {
if (chained)
console(" %lx upid: %lx nr: %d pid: %lx\n"
pnext/pprev: %.*lx/%lx task: %lx\n",
kpp, upid, upid_nr, pid, VADDR_PRLEN, pnext, pprev, next);
else
console("pid_hash[%4d]: %lx upid: %lx nr: %d pid: %lx\n"
" pnext/pprev: %.*lx/%lx task: %lx\n",
i, kpp, upid, upid_nr, pid, VADDR_PRLEN, pnext, pprev, next);
}
The console() function debug output, however, is a no-op
unless you first set up the "console" environment variable
with a tty name. Open another window on the system you're
running on, get its tty filename, and put it in a .crashrc
file located either in the current directory or home directory:
set console /dev/pts/<whatever>
You can set it to the same window as you're running the
crash session if you want -- the main reason the console()
function exists is to print often very verbose debug output
without trashing crash command output, so it allows you to
redirect it to another window.
Anyway, having done that, invoke "crash -d1", and you
should see output like this on the selected console
window, showing the task(s) found by walking each
in-use pid_hash[x] hlist_head:
...
pid_hash[ 11]: ffff81027c8f9048 upid: ffff81027c8f9038 nr: 666 pid: ffff81027c8f9000
pnext/pprev: 0000000000000000/ffff81000105b5d8 task: ffff81027c934000
pid_hash[ 19]: ffff81027f8012c8 upid: ffff81027f8012b8 nr: 1 pid: ffff81027f801280
pnext/pprev: 0000000000000000/ffff81000105b618 task: ffff81027ec5e000
pid_hash[ 27]: ffff81027cc2c748 upid: ffff81027cc2c738 nr: 378 pid: ffff81027cc2c700
pnext/pprev: 0000000000000000/ffff81000105b658 task: ffff81027cc9a000
pid_hash[ 74]: ffff81027ec589c8 upid: ffff81027ec589b8 nr: 35 pid: ffff81027ec58980
pnext/pprev: 0000000000000000/ffff81000105b7d0 task: ffff81027ee01160
pid_hash[ 119]: ffff81027cc35948 upid: ffff81027cc35938 nr: 2297 pid: ffff81027cc35900
pnext/pprev: 0000000000000000/ffff81000105b938 task: ffff81027d825160
...
Typically there's only one task on any pid_hash chain,
but if there's more than one, it will look like this
two-task example:
pid_hash[2920]: ffff81027d1b7c48 upid: ffff81027d1b7c38 nr: 528 pid: ffff81027d1b7c00
pnext/pprev: ffff81027f801748/ffff8100010610c0 task: ffff81027eef48b0
ffff81027f801748 upid: ffff81027f801738 nr: 7 pid: ffff81027f801700
pnext/pprev: 0000000000000000/ffff81027d1b7c48 task: ffff81027ec72000
Presumably in your case, (if you can reproduce it) there would have
been a pid_hash chain that contains ffff81012f0811d0 twice. Your debug
output is going to be extremely verbose, because you will see the
pid_hash output repeating itself 500 times -- but it will stop at the
pid_hash[index] where it found the duplicate entry.
I'm curious why you are seeing this. This pid_hash/retry scheme has
been in place forever, and I've never seen a legitimate/persistent
duplicate task error.
Thanks,
Dave
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
