On Dec 7, 2010, at 4:15 AM, David Berry wrote:
> On 7 December 2010 13:46, Brian McIlwrath <[log in to unmask]> wrote:
>> Hi David,
>>
>> I can take a look at the HDS algorithms again now that I should have fewer temporary file locators to examine!
>
> FYI, the problem I was referring to was the one noted (rather
> cryptically) by RFWS in ary1_temp.f - "This routine is a work-around
> to avoid the problems associated with calling DAT_TEMP if the objects
> created 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
I note that simply doing:
datTemp( "TESTME", 1, dims, &tloc, &status );
datAnnul( &tloc, &status );
does cause the HDS_SCRATCH.TEMP_1 locator to be freed so at the lowest levels HDS does seem to be doing the right thing. What I'm finding is that this code (just on its own in a little C file):
ndfTemp( &tmp_place, &status );
ndfNew ( "_INTEGER", 3, lbnd, ubnd, &tmp_place, &indf, &status );
ndfAnnul( &indf, &status );
leaves me with a dangling HDS_SCRATCH.TEMP_N locator (doing ndfBegin/ndfEnd doesn't help). NDF1_ANTMP is being called (although the locator count is not affected by the DAT_PRMRY and DAT_ERASE calls so I wonder what they are really doing).
--
Tim Jenness
Joint Astronomy Centre
|