On Wed, Oct 24, 2012 at 8:20 AM, HATAYAMA Daisuke
<d.hatayama@jp.fujitsu.com> wrote:
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