----- "Dave Anderson" <anderson(a)redhat.com> wrote:
And lastly, when I run a kernel with this patch against a set of
x86_64-only
dumpfiles, I get a segmentation violation like this on certain kdump
kernels:
...
please wait... (determining panic task)
Program received signal SIGSEGV, Segmentation fault.
0x000000000051c79c in get_netdump_panic_task () at netdump.c:719
719 len = roundup(len + note64->n_namesz, 4);
(gdb) bt
#0 0x000000000051c79c in get_netdump_panic_task () at netdump.c:719
#1 0x0000000000521ae5 in get_kdump_panic_task () at netdump.c:2316
#2 0x00000000004a5550 in get_dumpfile_panic_task () at task.c:5493
#3 0x00000000004a51b1 in panic_search () at task.c:5386
#4 0x00000000004a2ef6 in get_panic_context () at task.c:4574
#5 0x00000000004974ee in task_init () at task.c:456
#6 0x0000000000449e3a in main_loop () at main.c:536
...
And if I remove the call to map_prstatus_array(), it works OK again.
I haven't dug into what changed to cause the problem though...
The problem is this memset() statement, which makes no sense:
+void map_prstatus_array(void)
+{
+ void *nt_ptr;
+ int i, j;
+
+ /* temporary buffer to hold the prstatus_percpu array */
+ if ((nt_ptr = (void *)calloc(nd->num_prstatus_notes,
+ sizeof(void *))) == NULL)
+ error(FATAL,
+ "cannot allocate a buffer to hold prstatus_percpu array\n");
+
+ memcpy((void *)nt_ptr, nd->nt_prstatus_percpu,
+ nd->num_prstatus_notes * sizeof(void *));
+ memset(nd->nt_prstatus_percpu, 0, nd->num_prstatus_notes);
...because it zero's out the first few bytes (whatever the number of NT_PRSTATUS
sections there are) of the first entry in the array. So for example, here's
a before-and-after of the contents of a kdump's nd->nt_prstatus_percpu[] array
which has just 2 NT_PRSTATUS sections:
before memset():
1d9f5dc8 1d9f5f2c 0 0 0 0 0 0 0 0 0 0 0
after memset():
1d9f0000 1d9f5f2c 0 0 0 0 0 0 0 0 0 0 0
And then depending upon whether the resultant virtual address actually exists
in the crash utility's virtual address space, it craps out in
get_netdump_panic_task()
when it tries to access the faulty address.
Dave