<br><br><div class="gmail_quote">On Wed, Oct 24, 2012 at 8:20 AM, HATAYAMA Daisuke <span dir="ltr"><<a href="mailto:d.hatayama@jp.fujitsu.com" target="_blank">d.hatayama@jp.fujitsu.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">From: Lei Wen <<a href="mailto:adrian.wenl@gmail.com">adrian.wenl@gmail.com</a>><br>
Subject: Re: GCORE: add directly show backtrace function in crash<br>
</div>Date: Tue, 23 Oct 2012 17:06:58 +0800<br>
<div class="im"><br>
...<br>
<br>
>><br>
>> > Also a silly question, since kernel runs well with user symbol, why gdb<br>
>> > could not live with the chaos?<br>
>><br>
>> The premiss would be wrong. crash can work wrongly if user symbol is<br>
>> loaded. crash, and gcore, memoize the symbols they frequently refer to<br>
>> in memory for performance. It is done in early start-up phase before<br>
>> reaching crash's prompt. Such symbols memoized are not affected. But<br>
>> there are symbols not memoized in crash and gcore. They are of couruse<br>
>> affected.<br>
>><br>
>><br>
> Now I fully understand your concern, the same symbol would destroy kernel's<br>
> original cached one... Is there any method to let crash only use those<br>
> symbol<br>
> from kernel, and gcore use those from user space when try to do the<br>
> backtrace?<br>
<br>
</div>It's converse. Cached ones are not affected. Look at some global<br>
tables in global_data.c. I mean these. As long as crash feature can<br>
play its role only by these cached data, it's no problem because we<br>
don't need to look up symbol tables modified by loading of<br>
application's symbols.<br>
<br></blockquote><div><br></div><div>I see...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
gcore looks up symbol tables and initializes its own cache at the load<br>
of extension module. On the above example, I already loaded<br>
application's symbols before loading gcore module. So, gcore read<br>
application's task_struct symbol and used it as kernel's and behaved<br>
wrongly.<br>
<br></blockquote><div><br></div><div>I also did a test for first load gcore module, and then load the test file symbol.</div><div>This time, there would be no "<span style="background-color:rgb(255,255,255);color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">invalid structure member offset</span>" error.</div>
<div>But it would result another issue:</div><div><div>gcore: Restoring the thread group ... </div><div>gcore: done.</div><div>gcore: Retrieving note information ... </div><div>gcore: invalid kernel virtual address: 30a  type: "__task_pid_nr_ns: pids_type_pid"</div>
</div><div><br></div><div>As you said, the cached symbols are not affected, so why I load the test file</div><div>symbol later behavior would still cause gcore failure? Seems weird...</div><div><br></div><div>Thanks,</div>
<div>Lei</div></div>