x_haraldsen%use.uio.uninett@TOR.NTA.NO (Tore Haraldsen USE/UiO) (02/02/88)
My old C utilities (among them lzcomp/dcmp are failing after we installed VMS 4.6. I have traced the problems down to a sequence of malloc ... realloc ... free where the return value from malloc is stored in the address part of a standard VMS descriptor. The following realloc fails, and if realloc is removed, the free fails anyway. The code goes somewhat like this: fdl$desc->dsc$a_pointer = malloc (4096); ... fdl$desc->dsc$a_pointer = realloc (fdl$desc->dsc$a_pointer, newsz); ... free (fdl$desc->dsc$a_pointer); (writing from natures memory, my C is not that strong...) I have tried recompiling and reloading (i loaded with re-entrant VAXCRTL since disk space is scarce on my little machine), but to no avail. Anybody know what's wrong and how to get around it?? Tore Haraldsen University of Oslo Box 1059 Blindern N - 0316 Oslo 3 Norway x_haraldsen@inger.uio.no -------
jdc@naucse.UUCP (02/10/88)
In article <93*x_haraldsen@use.uio.uninett>, x_haraldsen%use.uio.uninett@TOR.NTA.NO (Tore Haraldsen USE/UiO) writes: > My old C utilities (among them lzcomp/dcmp are failing after we > installed VMS 4.6. > > I have traced the problems down to a sequence of > > malloc ... realloc ... free I had a similar problem with Todd Allen's MAKE program. I thought there was a problem with the run-time library, but it turned out that free was being called more than once on an old malloc pointer. As far as I know the old library routine had a "feature" that allowed free to be "harmless" if the block was previously deallocated. The new library seems to treat such cases prejudicially. My conclusion was that there really wasn't a "bug" in malloc/free, just a new behavior that turned up new run-time problems in code that needed fixing. If I'm wrong I'd like to hear about it. (I did get a fix for an ungetc problem in 4.6--fix is in 4.7). -- John Campbell ...!arizona!naucse!jdc unix? Sure send me a dozen, all different colors.