VxWorks memory error when closing ADA file

VxWorks memory error when closing ADA file

[jhuber]

I am running an ADA build in a VxWorks OS.  When
I close one of my log files, the OS states that
there is a memory deallocation error.  However,
the data is saved to the log file and the file
closes without any ADA errors or exceptions.
Moreover, the code to close the file is just:

     ADA.TEXT_IO.CLOSE(ERROR_FILE);

Finally, I use the same procedure in other log
files without any errors.

So, is there an alternative method I could try?
Or possibly a way to debug this error in ADA?

Re: VxWorks memory error when closing ADA file

[Jeff Creem]

vxWorks version? who's compiler? target type? host type? These might help...

Some notes:

 On vxWorks, if your file access is via FTP (unless you have a local disk or
have
specifically tried to make it via NFS it is probably via FTP). If it is ftp,
the file is not written to
the network until the file is closed. This means that the entire file stays
resident in RAM until the
close call is made. Perhaps if this is a large file you are running out of
memory.

If you can, do some memShow commands at the shell while the file is being
written to before it
closes.

Beyond that it is hard to say without more details since many of us have
used vxWorks and
Ada to create files before with no problems.

You could of course set a breakpoint at the close and then step into the OS
code to
get a better idea..

<jhuber@ellsworth.nlxcorp.com> wrote in message
news:%a0F6.96$284.2129@newsfeed.slurp.net...
> I am running an ADA build in a VxWorks OS.  When
> I close one of my log files, the OS states that
> there is a memory deallocation error.  However,
> the data is saved to the log file and the file
> closes without any ADA errors or exceptions.
> Moreover, the code to close the file is just:
>
>      ADA.TEXT_IO.CLOSE(ERROR_FILE);
>
> Finally, I use the same procedure in other log
> files without any errors.
>
> So, is there an alternative method I could try?
> Or possibly a way to debug this error in ADA?

Re: VxWorks memory error when closing ADA file

[Smark]

"Jeff Creem" <jeff@thecreems.com> wrote in message
news:Wv2F6.20517$bA2.5461988@typhoon.ne.mediaone.net...
>
> vxWorks version? who's compiler? target type? host type? These might help...
>
> Some notes:
>
>  On vxWorks, if your file access is via FTP (unless you have a local disk or
> have
> specifically tried to make it via NFS it is probably via FTP). If it is ftp,
> the file is not written to
> the network until the file is closed.

In fact, the same is true for file access via NFS.

Mark

Re: VxWorks memory error when closing ADA file

[Jeff Creem]

"Smark" <not.provided@all.com> wrote in message
news:9c3vp5$f2s4@cui1.lmms.lmco.com...
> "Jeff Creem" <jeff@thecreems.com> wrote in message
> news:Wv2F6.20517$bA2.5461988@typhoon.ne.mediaone.net...
> >
> > vxWorks version? who's compiler? target type? host type? These might
help...
> >
> > Some notes:
> >
> >  On vxWorks, if your file access is via FTP (unless you have a local
disk or
> > have
> > specifically tried to make it via NFS it is probably via FTP). If it is
ftp,
> > the file is not written to
> > the network until the file is closed.
>
> In fact, the same is true for file access via NFS.
>
> Mark
>

In fact unless they broke this for more recent versions of vxWorks, NFS did
not cache
the entire file in RAM prior to flushing it to the network nor does it read
the entire file into
RAM prior to allowing read calls to operate. If this is happening with your
target I suspect a configuration
problem.


Now, as for the original question I still wonder if perhaps the filesystem
is double mounted
(very typical if NFS is used that the device would be accessible both via
FTP and NFS and
just accessing the file via a different path would change the approach).

While it is always possible you have some RAM problem a much more likely
event would
be some sort of memory allocation/deallocation problem. Are you running with
Ada checks enabled?
Other than vxWorks is there any C code that is running?

Re: VxWorks memory error when closing ADA file

[Smark]

"Jeff Creem" <jeff@thecreems.com> wrote in message
news:%LoF6.21500$bA2.5861739@typhoon.ne.mediaone.net...
>
> "Smark" <not.provided@all.com> wrote in message
> news:9c3vp5$f2s4@cui1.lmms.lmco.com...
> > "Jeff Creem" <jeff@thecreems.com> wrote in message
> > news:Wv2F6.20517$bA2.5461988@typhoon.ne.mediaone.net...
> > >
> > > vxWorks version? who's compiler? target type? host type? These might
> help...
> > >
> > > Some notes:
> > >
> > >  On vxWorks, if your file access is via FTP (unless you have a local
> disk or
> > > have
> > > specifically tried to make it via NFS it is probably via FTP). If it is
> ftp,
> > > the file is not written to
> > > the network until the file is closed.
> >
> > In fact, the same is true for file access via NFS.
> >
> > Mark
> >
>
> In fact unless they broke this for more recent versions of vxWorks, NFS did
> not cache
> the entire file in RAM prior to flushing it to the network nor does it read
> the entire file into
> RAM prior to allowing read calls to operate. If this is happening with your
> target I suspect a configuration
> problem.

Actually, we use NFS precisely for the reason you mention about reading --
we don't always want to read the entire file into memory.

Regarding writing, there is a variable in nfsDrv, called "nfsCacheSize," which
determines how much data is cached in memory before writing to the external
file.  So, really, neither of us were completely accurate above.  If
nfsCacheSize is set higher than the typical file size, the behavior I
described will occur; if it is lower, the behavior you described happens.

FWIW, there is also a "FIOSYNC" ioctl function in nfsDrv, which can be used to
explicitly flush data to the remote file.

Mark

Re: VxWorks memory error when closing ADA file

[Simon Wright]

"Jeff Creem" <jeff@thecreems.com> writes:

> In fact unless they broke this for more recent versions of vxWorks,
> NFS did not cache the entire file in RAM prior to flushing it to the
> network nor does it read the entire file into RAM prior to allowing
> read calls to operate.

IIRC it uses 8k blocks.

Re: VxWorks memory error when closing ADA file

[jhuber]

I am using:
        VxWorks 5.3.1
        Green Hills ADA compiler 1.8.8E
        PPC 604 target
        SUN Sparc host
        Tornado 1.0.1

I know that the file size is not getting too large as there are larger log
files using the same procedures that do not produce any VxWorks errors.
Moreover, by using VxWorks, I found that the most memory ever used is 3/4
of the total available.  (However, the apps normally only consume about
half of the available memory.)  The only concern I have with memory is a
slight fragmentation problem.

Also, if the entire file appears to get written from target's RAM to the
file on the host, could there be a problem with the memory?  Just for an
example, is VxWorks allowed to define a memory partition if some portion
of this partition spills over into "protected" regions?  Or, could some
memory be corrupt?

Typical error messages (taken on two different occasions) are:

0x13c0cb8 (executive): memPartFree: invalid block 0x13ed1f0 in partition 
0x224804.
0x1a9d1c0 (executive): memPartFree: invalid block 0x1ad6100 in partition 
0x224804.

Re: VxWorks memory error when closing ADA file

[Ted Dennison]

In article <T4hF6.27$rk6.1363@newsfeed.slurp.net>, jhuber@ellsworth.nlxcorp.com
says...
>
>I am using:
>        VxWorks 5.3.1
>        Green Hills ADA compiler 1.8.8E
>        PPC 604 target
>        SUN Sparc host
>        Tornado 1.0.1


It would definitely be worth trying NFS. Text_IO and the vxWorks FTP devices
never played well together for me on Tornado 1.0.1

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: VxWorks memory error when closing ADA file

[Peter Richtmyer]

<jhuber@ellsworth.nlxcorp.com> wrote in message
news:%a0F6.96$284.2129@newsfeed.slurp.net...

> I am running an ADA build in a VxWorks OS.  When
> I close one of my log files, the OS states that
> there is a memory deallocation error

It would make sense to infer that a "memory deallocation error"
means that Ada did not have the problem. The OS did. And so
you "definitely" did not try to close the file twice. Nevertheless,
I will ask the question:

      Are you sure you did not try to close the file twice?

And what happens if you do not issue a "Close" at all?
Might be a cheap work-around, if it works, since the file
should get closed anyway (with most OS's at least).

Good Luck,
Peter

Re: VxWorks memory error when closing ADA file

[Jeff Creem]

>
>       Are you sure you did not try to close the file twice?
>
> And what happens if you do not issue a "Close" at all?
> Might be a cheap work-around, if it works, since the file
> should get closed anyway (with most OS's at least).
>
> Good Luck,
> Peter
>


Well...If text io is being used it can't be that since that should raise an
exception
rather than blow up.

As for the no close workaround....This does not work on vxWorks.

Re: VxWorks memory error when closing ADA file

[Peter Richtmyer]

"Jeff Creem" <jeff@thecreems.com> wrote in message
news:WiyG6.1414$9j1.638830@typhoon.ne.mediaone.net...
> >
> >       Are you sure you did not try to close the file twice?
> >
> > And what happens if you do not issue a "Close" at all?
> > Might be a cheap work-around, if it works, since the file
> > should get closed anyway (with most OS's at least).
> >
> > Good Luck,
> > Peter
> >
>
>
> Well...If text io is being used it can't be that since that should raise
an
> exception
> rather than blow up.
>
> As for the no close workaround....This does not work on vxWorks.
>

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.

How's that for pontification?

Cheers...
 Peter
"Expect the best..."

Re: VxWorks memory error when closing ADA file

[Jeff Creem]

----- 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?

Re: Shaking Dead Chickens - off topic (was VxWorks memory error when closing ADA file)

[Peter Richtmyer]

"Jeff Creem" <jeff@thecreems.com> wrote in message
news:60EG6.1867$9j1.744767@typhoon.ne.mediaone.net...

> Perhaps you have some additional advice about shaking a dead chicken over
the code
> to make the problem go away?
>

Now we are getting some where! Most of these threads have been
pretty boring since Robert split the scene. (I miss him)            :-)

I would like to declare you the winner of this one (if no one
else objects) and get back to my tarot session.                       :-)

regards,
Peter
"Expect the Best..."