[comp.realtime] vxWorks memory partitions

cmiller@hao.ucar.edu (Charlie Miller) (05/11/89)

The apparent problem: In the debug cycle of modify, load, try, modify, reload,
vxWorks eventually uses up all available memory by not deallocating partitions
allocated to each program loaded even though the new program has the same
name.  It just allocates new partitions until no more are available then
refuses to allow loads.  The only way I have found to get around this is
to manually do free(program_name) from the shell or to reset. There must be
a way to automate this process.

Any suggestions??

Also, I would like to hear from other vxWorks users out there.  What are
your applications, etc.

Charlie Miller
cmiller@hao.ucar.edu

wbrown@beva.bev.lbl.gov (Bill Brown) (05/11/89)

In article <3213@ncar.ucar.edu> cmiller@hao.ucar.edu (Charlie Miller) writes:
>
>The apparent problem: In the debug cycle of modify, load, try, modify, reload,
>vxWorks eventually uses up all available memory by not deallocating partitions
>allocated to each program loaded even though the new program has the same
>name.  It just allocates new partitions until no more are available then
>refuses to allow loads.  The only way I have found to get around this is
>to manually do free(program_name) from the shell or to reset. There must be
>a way to automate this process.
>
>Any suggestions??
>
>Also, I would like to hear from other vxWorks users out there.  What are
>your applications, etc.
>
>Charlie Miller
>cmiller@hao.ucar.edu


An interesting idea, this.  I've wanted to do something like this (similar
to the 'forget' word in FORTH) but never thought of trying 'free'.

I usually have more than one file that needs to be loaded and I use a
script like this:
	ld <framis_1.o
	ld <framis_2.o
	ld <doohickey.o
    which resides in a file called "ld_this_stuff"

After doing ->cd "host:~me/vxworks/current_dir" in invoke the script by
	<ld_this_stuff
    
Now it seems that if having another script called 'forget' (oops - FORTH again)
with a call to 'free' for each function ought to do it.  It gets invoked
before the first "ld" call in the load script.

A more elegant way of doing this would be to write a "forget" function
that gets loaded before the first "real" function.  When invoked, it would
use the symbol table to "free" the memory occupied by every function
loaded after itself and then perhaps it deletes itself.  (I'm fairly sure
that stuff gets put in the symbol table in the order it is loaded.)

It would be nice if something like this was included in the kernel prom.

Hmmmm - It shouldn't be too hard to write such a beast, but I don't have the
time right now to do it (right, Steve???).  If anybody does it I hope they
will share it.

							-bill
							WLBrown@lbl.gov
							(415)486-6411


Disclaimer:  These opinions are my own and have nothing to do with the
    official policy or management of L.B.L, who probably couldn't care 
    less about employees who play with trains.

biocca@bevb.bev.lbl.gov (Alan Biocca) (05/11/89)

In article <2603@helios.ee.lbl.gov> wlbrown@lbl.gov (Bill Brown) writes:
>In article <3213@ncar.ucar.edu> cmiller@hao.ucar.edu (Charlie Miller) writes:

>>The apparent problem: In the debug cycle of modify, load, try, modify, reload,
>>vxWorks eventually uses up all available memory by not deallocating partitions
>>allocated to each program loaded even though the new program has the same
>>name.  It just allocates new partitions until no more are available then
>>refuses to allow loads.  The only way I have found to get around this is
>>to manually do free(program_name) from the shell or to reset. There must be
>>a way to automate this process.

How about creating a load script that does 'free x' 'load x' ???????

>>Any suggestions??

>>Also, I would like to hear from other vxWorks users out there.  What are
>>your applications, etc.

>An interesting idea, this.  I've wanted to do something like this (similar
>to the 'forget' word in FORTH) but never thought of trying 'free'.

>I usually have more than one file that needs to be loaded and I use a
>script like this:
>	ld <framis_1.o
>	ld <framis_2.o
>	ld <doohickey.o
>    which resides in a file called "ld_this_stuff"

>After doing ->cd "host:~me/vxworks/current_dir" in invoke the script by
>	<ld_this_stuff
    
A convenient aid here is to enable the vxStartup feature of vxWorks and
create a vxStartup file that contains your startup and program load commands.
Then a periodic reboot of vxWorks is pretty painless.

vxWorks is being used here at Lawrence Berkeley Lab (LBL) for a number
of applications.  Initially it was purchased for the Keck Ten Meter Telescope
Active Control System to run the 108 motors that position the 36 hexagonal
main mirror segments to within a few nanometers.  The VME crate that performs
this control contains twelve CPU's running vxWorks.  It was later adopted for
much of the other subsystems within that project.  The next project at LBL
to obtain vxWorks was the BEVALAC Accelerator and we are currently using it
to bridge between the new Sun-based operator consoles and the old Modcomp
control system.  As time progresses we will be adding new controlled items
to the system via vxWorks and eventually replacing the older Modcomp based
controls.  Other projects here are in various stages of considering or
planning systems using vxWorks for NMR Research data acquisition and control,
magnetic measurements, physics experiments data acquisition, seismic data
acquisition and realtime analysis, and so on.

	Alan K Biocca

lewis@bevsun.bev.lbl.gov (Steve Lewis) (05/11/89)

From conversations with developers at Wind River Systems, the vendor of
the VxWorks product, a "forget" utility is not supplied because, in the
general case, it is not possible to guarantee that some other function that
was loaded later than the candidate function is not still referencing the
latter.

However, if the intention is to unroll the most recent series of loaded
functions in strictly LIFO order, and it is guaranteed that no spawned
tasks refer to any of the nested functions, than perhaps it is a
reasonable request.

	Steve Lewis
	Project Leader, Bevalac Controls
	415/486-5831
	SALewis@lbl.gov or as above

dat@noao.edu (D'Anne Thompson) (05/13/89)

From article <3213@ncar.ucar.edu>, by cmiller@hao.ucar.edu (Charlie Miller):
> 
> ........................  The only way I have found to get around this is
> to manually do free(program_name) from the shell or to reset. There must be
> a way to automate this process.
> 
> Any suggestions??
> 

I have already sent such a request directly to Wind River Systems.
Unfortunately, using 'free' in such a cavalier manner is not good practice.

'Free' should never be used with any argument that is not the result of a
previous 'malloc'.  In some implementations it may work and in others it
may not work.  It may appear to work but cause problems down the road.

The proper way to unload a module is to undo each 'malloc' in the reverse
order.  Then there is the problem of symbol table entries which point into
the 'free'd space.  Assuming you are going to just reload a corrected
module each symbol table entry will be redefined and there is no problem.
But if not, then you are in danger of having symbols point into unknown
memory spaces.  To correct the symbol table you either have to purge those
symbols or at least redirect them to 0x0, or non-existant memory, to
nullify them somehow.

We are very happy users of vxWorks (4.0.1).  An internal memo of our
experiences with vxWorks is available upon request.  The memo includes
bugs and bug fixes, suggestions for improvements in vxWorks, and
a description of library packages that are available for outside
distribution.  I will not put the memo on the net.  It is available
for direct mailing only.

D'Anne Thompson
National Optical Astronomy Observatories
P.O. Box 26732
Tucson, Az  85726
(602) 325-9335
dat@noao.edu   (for uucp try {..}!uunet!noao.edu!dat)