jrd@STONY-BROOK.SCRC.SYMBOLICS.COM (John R. Dunning) (07/10/88)
I'm in the throes of porting GNU Make, and have run into what looks like some kind of problem with gulam. The symptom is: when Make decides it needs to execute a command, it formats up the command name and arglist, and hands them off to a CLI. My CLI-finding routine does the obligatory lookup thru #x4F6, and jsr's to the resultant address, gulam's command executing routine in this case. The command gets executed perfectly, but when gulam returns to me, large tracts of memory have been trashed, including my stack. As you might imagine, things deteriorate in rapid fashion after that. Commenting out the actual JSR to gulam prevents the lossage. Pexec'ing the image directly causes no trouble. It happens repeatably (same garbage at same address) if I execute it a bunch of times. The same sort of thing (different values) happens with gulam 1.00.00.02 and 1.03.04.05. I'm not sure exactly what range of addresses are getting trashed, but it's at least in the range of a K or so, as I've dumped that much stack before and after the call, and seen it trashed. Anyone out there ever seen anything like this, or have any idea how to go about tracking down exactly what's happening?
roeder@sbsvax.UUCP (Edgar Roeder) (07/11/88)
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
gert@nikhefh.UUCP (07/12/88)
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).