On 9 December 2010 19:32, Tim Jenness <[log in to unmask]> wrote:
> On Dec 9, 2010, at 5:17 AM, Brian McIlwrath wrote:
>
>>>
>>> must subsequently be erased."
>>>
>>> Changing the HDS leaking code to use "ALOCATORS" instead of "LOCATORS"
>> in smurf_mon.c I'm still getting leaking >locators of the form
>>>
>>> HDS_SCRATCH.TEMP_2
>>
>> Hi Tim,
>>
>> I have been looking with gdb and, from limited experimentation, it looks
>> there are two locators TEMP_1(ARY_TEMP) and TEMP_2(NDG_TEMP) which are
>> still being left connected to the temporary file after monolith run. In
>> an ideal world they should perhaps go as well but - as they are just the
>> "top_level" locators for ARY and NDG structures they are perhaps not
>> crucial - unless we DO still want to delete the temporary file between
>> iterations!
>>
>
> I was more intrigued as to why datTemp was managing to get the parent locator removed whereas NDF_TEMP didn't. I couldn't understand why NDF1_ANTMP wasn't working like that. Maybe David could have a look. Maybe my datTemp example wasn't good enough because I don't create any structures with the locator.
I'm not sure what the problem is that we are trying to solve now. Is
it trying to understand the reason why the RFWS approach to allocating
and freeing temporary HDS objects works, but simple use of HDS does
not (always) work?
David
|