neil@yc.estec.nl (Neil Dixon) (08/15/89)
When running a sbdl program I use delete_all_segments to delete all my current segments. However it appears that the memory used by the deleted display list is not freed. Anyone know how I can free this memory? -- Neil Dixon <neil@yc.estec.nl> UUCP:...!mcvax!esatst!neil, BITNET: NDIXON@ESTEC Thermal Control & Life Support Division (YC) European Space Research and Technology Centre (ESTEC), Noordwijk, The Netherlands.
stroyan@hpfcdc.HP.COM (Mike Stroyan) (08/17/89)
> When running a sbdl program I use delete_all_segments to delete all my > current segments. However it appears that the memory used by the > deleted display list is not freed. Anyone know how I can free this memory? > -- > Neil Dixon The display list is using malloc() and free() to allocate and release the memory. The call to delete_all_segments() will result in calls to free() all of the malloc'd memory, but the malloc library does not reduce process size when memory is freed. The free memory is placed on a list of free memory that can be used by future malloc operations. If you only want to be able to malloc more memory, then you have no problem. If you want to reduce the size of the process to use less swap space, then you have a problem with no easy answer. The malloc(3C) and malloc(3X) libraries use the brk(2) and sbrk(2) kernel calls to allocate additional data space. They never reduce the data space. You would need to replace the malloc library with one that will reduce the data space when possible. There is only a limited chance of reduction being possible. All malloc'd memory above a given address must have been freed before the data space can be reduced to that maximum address. If any library has malloc'd memory above the large block of memory used by display list segments, then the former display list memory can not be released from the data space. Mike Stroyan, stroyan@hpfcla.hp.com
neil@yc.estec.nl (Neil Dixon) (08/18/89)
In article <5570267@hpfcdc.HP.COM> stroyan@hpfcdc.HP.COM (Mike Stroyan) writes: >free() all of the malloc'd memory, but the malloc library does not >reduce process size when memory is freed. The free memory is placed on >a list of free memory that can be used by future malloc operations. > >If you only want to be able to malloc more memory, then you have no >problem. If you want to reduce the size of the process to use less swap >Mike Stroyan, stroyan@hpfcla.hp.com Maybe I'm doing something wrong, but if I create a display list, delete it using delete_all_segments then recreate exactly the same list, the process size increases. Has this anything to do with the fact that I'm not using -lmalloc. I can't use this since I'm using the X toolkit in the same program and XtMalloc chokes when -lmalloc is used. -- Neil Dixon <neil@yc.estec.nl> UUCP:...!mcvax!esatst!neil, BITNET: NDIXON@ESTEC Thermal Control & Life Support Division (YC) European Space Research and Technology Centre (ESTEC), Noordwijk, The Netherlands.
stroyan@hpfcdc.HP.COM (Mike Stroyan) (08/21/89)
> Maybe I'm doing something wrong, but if I create a display list, > delete it using delete_all_segments then recreate exactly the same > list, the process size increases. Has this anything to do with the > fact that I'm not using -lmalloc. I can't use this since I'm using the > X toolkit in the same program and XtMalloc chokes when -lmalloc is > used. You certainly seem to be doing something different. The product test suite does verify that all malloc's are balanced by free's. A simple test I ran checking sbrk(0) results showed perfect reuse with and without linking in -lmalloc. Without more information I'm pretty well restricted to taking shots in the dark, but here are a few possibilities. - There is some element sequence in your segments that isn't freed correctly by delete_all_segments. - Your delete_all_segments call has the wrong file descriptor. - The display list malloc areas are intermixed with Xt malloc areas, and memory framentation is taking up more space when allocating around the other malloc areas. - The malloc free list is getting trashed by code writing outside of a malloc area. This possibilty is made more likely since you said that "XtMalloc chokes when -lmalloc is used". The -lmalloc library works fine for me with Xt. The two malloc libraries produce different amounts of padding and different results when memory outside of malloc areas becomes trashed. The usual result of this is a segment fault, but more subtle effects are possible. - There was a memory leak problem with -lmalloc that was fixed in the 6.5/3.1 releases. There may be some similar problem with libc malloc that shows up in your circumstances. Mike Stroyan, stroyan@hpfcla.hp.com