This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [RFC PATCH] Fix segmentation fault of listing kprocess.create
- From: Josh Stone <jistone at redhat dot com>
- To: "wenji dot huang at oracle dot com" <wenji dot huang at oracle dot com>
- Cc: "systemtap at sourceware dot org" <systemtap at sourceware dot org>
- Date: Fri, 06 Nov 2009 16:14:14 -0800
- Subject: Re: [RFC PATCH] Fix segmentation fault of listing kprocess.create
- References: <20091105153851046.00000002852@ETSD-Ora-lap2>
On 11/04/2009 11:38 PM, Wenji Huang wrote:
> Hi,
>
> Sorry for a little annoying thread. ^-^
>> Please ignore the previous patch, the root cause is the
>> following section
>> tapsets.cxx: dwarf_derived_probe::saveargs
>>
>> /* trick from visit_target_symbol_context */
>> target_symbol *tsym = new target_symbol;
>> token *t = new token;
>> tsym->tok = t;
>> tsym->base_name = "$";
>> tsym->base_name += arg_name;
>>
>> The empty token is created, I will fix it soon.
>> Also any suggestion is welcome!
>>
> Take a deep look. Seems we will try to access the variables in
> return probe. It's fully supported or not? Guess not.
>
> If not, the function should return early once has_return is true.
> If yes, we will hypothesize accessing the argument. And the
> source_loc of t has to be q.base_loc since no real one.
You were on to the real problem here, and then you and Frank kept
talking about token pointers... Yes, we do support reading variables in
a return probe, but that's playing funny games with saveargs.
The issue is that when a $var is accessed in a return probe, the
dwarf_var_expanding_visitor will create a matching .call which does the
real $var access. The .call will get resolved later, so within this
saveargs it will always appear successful.
I committed d87623a which momentarily suspends the has_return status, so
that dwarf_var_expanding_visitor won't try to do anything funny. This
appears to work for me, so let me know if it still gives you trouble.
Josh