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)