sasaki@HARVARD.HARVARD.EDU.UUCP (12/19/86)
I've been having problems with getting VMS GNU Emacs working completely and think that I may have stumbled upon a serious problem. According to the documentation for VAX-11 C you can't use malloc, calloc, etc., with brk and sbrk. Gnu Emacs uses brk and sbrk, but does it's own version of malloc, realloc, etc. This is fine, but it appears that getenv (amoung others) calls calloc. This then violates the rule about mixing allocation routines. Now it makes perfect sense that I should be seeing a problem here. What I am wondering about though, is why the older version of GNU Emacs works at all, since it uses the getenv, and brk and sbrk. This could explain the mysteriousness of 17.VMS-4. Could someone enlighten me? ---------------- Marty Sasaki uucp: harvard!sasaki Strategic Information arpa: sasaki@harvard.harvard.edu 80 Blanchard Road bitnet: sasaki@harvunxh Burlington, MA 01803 phone: 617-273-5500
montnaro%chenengo.tcpip@GE-CRD.ARPA.UUCP (12/19/86)
Received: by chenengo.steinmetz (3.2/1.1x Steinmetz) id AA09105; Thu, 18 Dec 86 23:06:55 EST Date: Thu, 18 Dec 86 23:06:55 EST From: Skip Montanaro <montnaro%chenengo.tcpip@csbvax> Posted-Date: Thu, 18 Dec 86 23:06:55 EST Message-Id: <8612190406.AA09105@chenengo.steinmetz> To: sasaki@harvard.harvard.edu Cc: vms-gnu-emacs@harvard.harvard.edu, info-vax@sri-kl.arpa In-Reply-To: sasaki%harvard.HARVARD.EDU.tcpip@csbvax.steinmetz's message of 18 Dec 86 21:54 EST Subject: malloc, alloc, etc., and brk and sbrk Marty Sasaki writes: According to the documentation for VAX-11 C you can't use malloc, calloc, etc., with brk and sbrk. Gnu Emacs uses brk and sbrk, but does it's own version of malloc, realloc, etc. This is fine, but it appears that getenv (amoung others) calls calloc. This then violates the rule about mixing allocation routines. I tried the following trivial test program (no comments on it please. it served my purposes.) ------------------------------------------------------------------------------ extern int getenv(); malloc(n) unsigned n; { static int space[1024]; return space; } main () { printf("%s\n", getenv("TERM")); } ------------------------------------------------------------------------------ I compiled and linked it with /DEBUG. When I linked it with the shareable RTL the linker said my version of malloc() was multiply defined. When I linked it with the normal RTL the version in the RTL turned up multiply defined. When I ran the latter version and set a break at malloc() it stopped when entering my version (not so with the shareable version). I suspect that the malloc()/brk() restriction is a non-problem with the current version of VMS GNU Emacs, since it does not appear to be linked with the shareable RTL. I think the GNU version of malloc() is being referenced. However, I routinely linked the old version (17.VMS-4) with the shareable RTL with no apparent problems. In fact, that's what we use on our VMS VAXen. Skip Montanaro ARPA: montanaro%desdemona.tcpip@ge-crd.arpa UUCP: seismo!rochester!steinmetz!desdemona!montanaro GE DECnet: csbvax::mrgate!montanaro@desdemona@smtp@tcpgateway
carl@CITHEX.CALTECH.EDU (Carl J Lydick) (12/20/86)
This sounds like it may be related to the fact that on UNIX systems, successive calls to brk or sbrk allocate contiguous chunks of memory, while on VMS any of a number of things (e.g., a call to RMS) can allocate a chunk of memory between the two allocated to the calls to [s]brk. The result is that if you are lucky enough (in the short run; in the long run, it's a definite stroke of bad luck) to make the calls to things that allocate memory in the right order, you might be able to port something from UNIX to VMS even without being careful about allocating memory. Of course, next time you change the program, you may find that the whole thing has to be rewritten to avoid the problem. If you've got source, you may want to check for instances in which multiple calls to [s]brk assume they get contiguous memory. It worked to device-independent troff and at least one other piece of software ported from UNIX; it may work for EMACS.
garry@TCGOULD.TN.CORNELL.EDU (Garry Wiegand) (12/22/86)
Try malloc'ing and then freeing a bunch of memory at the top of the program, sufficient to take care of any random getenv(), open(), etc calls that may come up during the life of the program. Or fix emacs not to assume that it has complete 100% control over sbrk()-style memory allocating. That's dangerous even on a Unix system. Sbrk() and malloc() can always be mixed freely; the danger is in assuming that different calls to sbrk will return consecutive memory locations. garry wiegand (garry%cadif-oak@cu-arpa.cs.cornell.edu)