[Pvfs2-developers] Re: pointer aliasing and interface->set_info semantics

[Troy Benjegerdes]

Scott Atchley wrote:
> On Mar 4, 2008, at 6:58 PM, Pete Wyckoff wrote:
>
>> troy at scl.ameslab.gov wrote on Tue, 04 Mar 2008 17:35 -0600:
>>> It looks like the IB BMI layer is ending up double-freeing the 
>>> method_addr
>>> structure on the BMI_ib_set_info function, but it only happens when the
>>> Metadata server is also a data server.
>>>
>>> If you look at the following GDB output, the last two entries have 
>>> the same
>>> method_addr, and I can't figure out a good way to tell in 
>>> BMI_set_info if
>>> the method_address has already been freed. It also looks like the 
>>> id_string
>>> has been mangled or freed somewhere earlier as well.
>>
>> All your deadref were different values there, so I'm not seeing the
>> double-free aspect.  But I have no doubt that you're on to something
>> in here.  Also, at this location, the id_string and method_addr have
>> already been freed, so we shouldn't count on them having reasonable
>> values in them.
>>
>> I've always had a hard time keeping these references straight.  Can
>> you verify that you're getting to these spots via dealloc_ref_st(),
>> and maybe a couple steps up from there, for sanity?
>>
>> Trying to figure out what other devices do in the DROP_ADDR handler.
>> MX goes and calls bmi_method_addr_forget_callback() in there, but
>> that doesn't seem right, as it will just wind around through
>> dealloc_ref_st() again.  It looks like TCP is doing more or less
>> what IB is doing.
>
> Pete,
>
> I do not see where bmi_ib uses bmi_method_addr_forget_callback() at 
> all. I am looking at the tcp code and I do need to fix how/where I use 
> the above.
>
> Scott
Scott, have you ever tried running pvfs2-ls with MX under valgrind? In 
my case I had 3 servers, and the double-free went away when I removed a 
second tcp:// alias separated by commas in the config file.