Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!andante!mit-eddie!bbn!uwmcsd1!marque!uunet!mcvax!nikhefh!gert From: gert@nikhefh.UUCP Newsgroups: comp.sys.atari.st Subject: Re: Gulam problem Message-ID: <486@nikhefh.hep.nl> Date: 12 Jul 88 08:20:02 GMT References: <19880710165749.2.JRD@MOA.SCRC.Symbolics.COM> <531@sbsvax.UUCP> Reply-To: gert@nikhefh.hep.nl (Gert Poletiek) Organization: Nikhef-H, Amsterdam (the Netherlands). Lines: 61 In article <531@sbsvax.UUCP> roeder@sbsvax.UUCP (Edgar Roeder) writes: > >I have had the same problems with my shell (Master V5.0). If Gulam allocates >memory (for making history-entries etc.) inside a system()-call, TOS gives this >memory to the currently running program (and this is your MAKE). After your >MAKE has finished, the memory is cleared and all eventual housekeeping- >information of the local Gulam-malloc() is erased. Because Gulam uses its own >blocks of memory (about 16k) this problem shows up only after some time (when >these 16k are all used up and a new Malloc()-call has to be done). There >are several solutions to this problem: > - try to get enough memory to the local (Gulam-)pool before running > your program, > - tell TOS, that the current program is Gulam (this is very difficult > to manage), or > - make your programs data space resident by calling Ptermres(0,0L) > (after Free()-ing all your locally Malloc()-ated blocks) > - inherit all your memory to the calling process (difficult, you have > to access the list of allocated memory-blocks and change the owner) > - use Master, it has no such problems (:-) >I hope this will clarify the situation a bit. > >Edgar The shell in the CRAFT development system also allows child processes to directly call the (already) resident shell. This shell has none of the problems mentioned. It is true however that allocating memory during execution of a system() call is tricky, but judging from the original complaint about Gulam handling system() calls from the Metacomco make utility Gulam seems to have other problems as well. The original complaint stated that more or less random areas of memory got trashed (near the location to where the stack pointer points in the process doing the system() call to Gulam). As far as I can see Gulam also executes the system call on the callers stack. This is very dangerous as the Gulam has no way predicting how complicated a system() call will be in terms of stack depth needed for parsing the command. Suppose the command to be executed is a shell script using multi level if-then-else constructs. I tried this calling Gulam from a program with about 1K stack space: you'll get a nice white screen followed by a hard reset... If you continue to have problems like these you should get a copy of the CRAFT environment. This will solve all your problems regarding 'make' since it contains a full blown make, a C shell compatible shell (more than 100 commands), the fastest editor available on the ST. Version 2.0 (just released) is available from: Creative Computing Media Tel. +..31-20-231740 Amsterdam, Holland. Gert Poletiek NIKHEF-H, Dutch National Institute for Nuclear and High Energy Physics Kruislaan 409, P.O.Box 41882, 1009 DB Amsterdam, The Netherlands UUCP: {decvax,cernvax,unido,seismo}!mcvax!nikhefh!gert bitnet: nikhefh!gert@mcvax.bitnet, U00025@hasara5.bitnet Disclaimer: Yes, I know, I am biased (I co-wrote the CRAFT system).