Hi Dave and other list readers,
First, just like some other contributors, I've come across an issue
triggered by a dump being corrupt. In my case it's this code in
kernel.c:cpu_maps_init():
if (*maskptr & (0x1UL << c)) {
cpu = (i * BITS_PER_LONG) + c;
kt->cpu_flags[cpu] |= mapinfo[m].cpu_flag;
}
The mask is corrupt, making Crash believe there are more CPU's than the
four we have allocated space for in kernel.c:kernel_init. How do you
think this should be handled?
Second, I believe there is a double free in the trace extension. When
ftrace_init_pages() fails it will free
cpu_buffer->pages
and
cpu_buffer->linear_pages
But when ftrace_init_pages() fails, ftrace_init_buffers() will call
ftrace_destroy_buffers() which also free's this space. For me this
resulted in a segfault in a malloc() a little later.
Regards,
Per
diff --git a/extensions/trace.c b/extensions/trace.c
index 34fc85f..831cc77 100644
--- a/extensions/trace.c
+++ b/extensions/trace.c
@@ -320,8 +320,6 @@ done:
return 0;
out_fail:
- free(cpu_buffer->pages);
- free(cpu_buffer->linear_pages);
return -1;
}
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
