I've not got any concrete information about subpar to offer here, but
the problem of tracking the opening and closing of files deep within
HDS sounds a bit like the problem I face regularly of tracking the
creation and deletion of objects deep within AST, in that they are
both controlled by reference counts that can be changed almost
anywhere in the package. For AST, I've found a very useful trick is to
put a printf in the function that does the incrementing and
decrementing of the reference count, that prints out the object name
and current reference count. I then use the dubugger to break there
when any unexpected increments or decrements occur, and examine the
call stack to see where and why the change in reference count
occurred. This way I usually manage to track down why an object is not
being deleted (equivalent to closing the file in your case). Looking
at HDS, modifying the rec_refcnt.c file by including something like:
#include <stdio>
...
printf( "Changing ref count for %s from %d to %d\n",
rec_ga_fcv[ han->slot ].name,
rec_ga_fcv[ han->slot ].count,
rec_ga_fcv[ han->slot ].count + inc );
may be informative. Presumably you would have to use some logging
function instead of printf. How you use a debugger when running
orac-dr, I'm not sure. Does the same problem occur under ICL?
David
On 14/06/07, Tim Jenness <[log in to unmask]> wrote:
> On Wed, 13 Jun 2007, Brad Cavanagh wrote:
>
> > ==13509== Open file descriptor 29:
> > /home/bradc/data/oracdr/reduced/uist/20070608/adam_13501/GLOBAL.sdf
>
> We got this to come up because we disabled the hds exit handler (Which
> usually closes all these) on the basis that valgrind will never report
> them if the exit handler runs but what's relevant to oracdr is the state
> following an obey not the state following the A-task shutdown.
>
> It would seem that if, for performance reasons, the parameter files are
> not closed after an action then if two monoliths modify GLOBAL.sdf that
> the first monolith will start to get confued. The private parameter files
> don't cause a problem because no-one else is writing to them.
>
> pcs/subpar is a bit convoluted and whilst it looks like the locator is
> being annulled and the file is being closed, reference counting is keeping
> it open (via lots of linking and cloning) and it's not clear after a
> simple analysis which particular locator is keeping the parameter file
> open. Is there a subpar call that can be issued for A-tasks at the end of
> the action to close all the parameter files?
>
> sup_deact seems to imply that GLOBAL is opened and closed when parameters
> are written at the end, but it makes no statement concerning GLOBAL.sdf
> being opened for read earlier.
>
> Searching for 'GLOBAL' indicates that it's hard-wired into sup_deact.f and
> pcn_setpp.f/setvp.f (which uses that to indicate SUBPAR__GLOBAL).
>
> --
> Tim Jenness
> JAC software
> http://www.jach.hawaii.edu/~timj
>
>
> _______________________________________________
> Stardev mailing list
> [log in to unmask]
> http://mailman.jach.hawaii.edu/mailman/listinfo/stardev
>
--
Note my change of e-mail address. Please send e-mail to
[log in to unmask] from now on.
|