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

[Lei Wen]

On Wed, Oct 24, 2012 at 8:20 AM, HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com
> wrote:

> From: Lei Wen <adrian.wenl at gmail.com>
> Subject: Re: GCORE: add directly show backtrace function in crash
> Date: Tue, 23 Oct 2012 17:06:58 +0800
>
> ...
>
> >>
> >> > Also a silly question, since kernel runs well with user symbol, why
> gdb
> >> > could not live with the chaos?
> >>
> >> The premiss would be wrong. crash can work wrongly if user symbol is
> >> loaded. crash, and gcore, memoize the symbols they frequently refer to
> >> in memory for performance. It is done in early start-up phase before
> >> reaching crash's prompt. Such symbols memoized are not affected. But
> >> there are symbols not memoized in crash and gcore. They are of couruse
> >> affected.
> >>
> >>
> > Now I fully understand your concern, the same symbol would destroy
> kernel's
> > original cached one... Is there any method to let crash only use those
> > symbol
> > from kernel, and gcore use those from user space when try to do the
> > backtrace?
>
> It's converse. Cached ones are not affected. Look at some global
> tables in global_data.c. I mean these. As long as crash feature can
> play its role only by these cached data, it's no problem because we
> don't need to look up symbol tables modified by loading of
> application's symbols.
>
>
I see...


> gcore looks up symbol tables and initializes its own cache at the load
> of extension module. On the above example, I already loaded
> application's symbols before loading gcore module. So, gcore read
> application's task_struct symbol and used it as kernel's and behaved
> wrongly.
>
>
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...

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