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 was going to limit my functionality change at the end of each
> iteration to "uncaching" the HCB and block data - so that hdsdump and/or
> hdstrace could be run on the files (at the minute they are claimed to be
> invalid - as the hcb data is cached)
Ok.
What I can do is modify hdsInfoI so that "LOCATORS" does not report on "HDS_SCRATCH.TEMP_N" but will report on HDS_SCRATCH.TEMP_N.XXX. Then that will fix normal leak checking in the monoliths.
--
Tim Jenness
Joint Astronomy Centre
|