[RFC PATCH] Fix segmentation fault of listing kprocess.create

[Josh Stone]

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