>Hello,
>
>makedumpfile-1.6.0 was scheduled in May, but still there is a
>unresolved issue so the release will be delayed.
>
>The issue is that the multi-thread feature doesn't work correctly
>on ia64, the generated dump is indefinite.
>The dumps below are generated by the same option (-cd31 + --num-thread=3).
>
> # ls -l
> -rw------- 1 kumagai kumagai 20607646 May 30 15:58 dumpfile.cd31-num3_take1
> -rw------- 1 kumagai kumagai 20604049 May 30 16:14 dumpfile.cd31-num3_take2
> -rw------- 1 kumagai kumagai 20603551 May 30 16:15 dumpfile.cd31-num3_take3
> -rw------- 1 kumagai kumagai 20603551 May 30 16:16 dumpfile.cd31-num3_take4
> -rw------- 1 kumagai kumagai 20607612 May 30 16:42 dumpfile.cd31-num3_take5
>
>This happen only on ia64, doesn't happen on x86_64 and i386. So I suppose that
>this issue came from overlapped PT_LOAD.
>
>I'll continue to investigate, thanks for your patient.
I found that this issue was caused by just typo in readpage_elf_parallel().
v1.6.0 can be released in this week, please wait just a little longer.
Thanks
Atsushi Kumagai
--
Author: Atsushi Kumagai <ats-kumagai at wm.jp.nec.com>
Date: Mon Jun 6 16:16:42 2016 +0900
[PATCH] Fix read data corruption for multi thread feature.
Fix the typo that was injected when rewriting
readpage_elf_parallel(). This bug can cause read data
corruption in multi thread processing.
Signed-off-by: Atsushi Kumagai <ats-kumagai at wm.jp.nec.com>
diff --git a/makedumpfile.c b/makedumpfile.c
index 8a80976..853b999 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -736,7 +736,7 @@ readpage_elf_parallel(int fd_memory, unsigned long long paddr, void *bufptr)
size -= paddr - phys_start;
if (size > endp - p)
size = endp - p;
- if (!read_from_vmcore_parallel(fd_memory, offset, bufptr,
+ if (!read_from_vmcore_parallel(fd_memory, offset, p,
size)) {
ERRMSG("Can't read the dump memory(%s).\n",
info->name_memory);
