Re: VxWorks memory error when closing ADA file

["Jeff Creem" <jeff@thecreems.com>]

----- Original Message -----
From: "Peter Richtmyer" <pmr@efortress.com>
Newsgroups: comp.lang.ada
Sent: Saturday, April 28, 2001 8:52 AM
Subject: Re: VxWorks memory error when closing ADA file

....some stuff deleted but I think the quoted stuff is all still in
context...


> I'm "sure" you are right, because you are "sure" that you are right.
> And he was "sure" the code should work. Sometimes we are so
> "sure" that a possible solution would not work that we do not even
> try something. And usually we are right. Almost always. And most
> of our code is always right. Except for...                   :-)
>
> Hey, maybe he is getting the ERROR because the name of the file
> is "ERROR_FILE"     :-)
>
> All he needs to do is change the name to "NO_ERROR_FILE"    :-)
>
> OK, I am being absurd to say that finding errors is easier if
> you are willing to explore ALL the possible causes, readily
> sorting them in your mind as to which are more likely. And some
> times it pays to just try something we are "sure" will not fix it,
> because it fixes it.
>



Wow...That was a lot of fun to read..I probably should have been more clear.

When I said not closing the file would not work (since as you
said earlier the OS would usually clean things up) in vxWorks I did
not mean that it was an approach that would not be able to solve
his problem...I meant that it just will not work under vxWorks at all.

vxWorks will indeed NOT close the file when your program terminates since
it never really knows for sure that other vxWorks tasks won't be accessing
it.

Now it is possible that if you declare your file type inside a procedure
("on the stack") that
perhaps the Ada runtime might close and clean up for you but certainly
not the OS. Perhaps this might even work for a package level variable but
again only if it is a file accessed via Ada file routines and then again it
would
only be if the run-time did it.



As for the rest of that babble..Whenever I have seen people "fix" problems
via
a method that should not have fixed it usually comes back to bite them
later. It only
(in my small mind) is actually a real fix if the "strange" fix brings you to
a solution
that not only appears solves the problem but also lets you understand why
the problem
originally existed.

Of course by now we have strayed pretty far off topic and still not helped
the
original poster so any additional verbal battles should be taken to e-mail.
Perhaps
you have some additional advice about shaking a dead chicken over the code
to
make the problem go away?