[Crash-utility] GCORE: add directly show backtrace function in crash

[Lei Wen]

Hi Daisuke,

I also did a test for first load gcore module, and then load the test file
> symbol.
> This time, there would be no "invalid structure member offset" error.
> But it would result another issue:
> gcore: Restoring the thread group ...
> gcore: done.
> gcore: Retrieving note information ...
> gcore: invalid kernel virtual address: 30a  type: "__task_pid_nr_ns:
> pids_type_pid"
>
> As you said, the cached symbols are not affected, so why I load the test
> file
> symbol later behavior would still cause gcore failure? Seems weird...
>
>
Finally I find the reason why load module first still has issue...
For task_struct/group_leader, gcore still use the MEMBER_OFFSET, so it
would try
to get this member offset each time instead of using the cached one.
Then if the symbol is changed by like user space, the gcore would be
directly confused.

Here is a fix for it.
diff --git a/extensions/libgcore/gcore_coredump_table.c
b/extensions/libgcore/gcore_coredump_table.c
index 2ae64df..e18f4c8 100644
--- a/extensions/libgcore/gcore_coredump_table.c
+++ b/extensions/libgcore/gcore_coredump_table.c
@@ -229,8 +229,7 @@ __task_pid_nr_ns(ulong task, enum pid_type type)
                ulong pids_type_pid;

                 if (type != PIDTYPE_PID)
-                       readmem(task + MEMBER_OFFSET("task_struct",
-                                                    "group_leader"),
+                       readmem(task +
GCORE_OFFSET(task_struct_group_leader),
                                KVADDR, &task, sizeof(ulong),
                                "__task_pid_nr_ns: group_leader",
                                gcore_verbose_error_handle());

Thanks,
Lei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20121031/a1c860ca/attachment.htm>