MICPRF@latvax8.lat.oz (05/08/90)
My problem is this - how do I stop unix system calls from failing due to lack of space when made from a large process. I know there is actually enough memory available, but the C library subroutines popen and system apparently don't, despite my changing the value of MAXMEM in <param.h> - for more info. see below. In article <413@latvax8.lat.oz> in aus.stats.s, I wrote: > Anyone out there who can figure this out? > In order to install new S on my Unix box I added another 4 Mbyte > RAM - my system does not have paging. > I then installed NEW S. > Everything works fine except for unix calls and functions that depend > on them. > If I install restricted new S the unix calls work fine, but I don't > have access to all the S functions of course. > After a failed attempt to use the unix function, for example > after date(), or help() > I get error messages saying call to UNIX failed : Not enough space > or something to the effect that the UNIX call returned a status of -1 > In all cases the object last.dump contains a series of messages > No frame available. > I can't figure out where the problem is. I can't believe that there > is not enough RAM as I now have 5.75 Mbyte free for S and nothing > like that amount seems to be allocated. In any case all the other > things seem to work ok when I run the tests. Only unix calls dont. > Any ideas? A couple of people suggested I was running out of swap space - thanks for the hint, but that wasn't the problem. I know a little more about it now (I think), but still need advice - I believe the problem is that the system limit on the size of a process is set at a now unrealistically low level (~1.2 Mbytes) in /usr/include/param.h I altered this and regenerated unix, then remade S - to no avail, and perhaps not surprisingly (?) because the C libraries were of course compiled with the old values in param.h. My problem now is that I don't have (wasn't supplied with) the source code for the C libraries. The closest I can get is to disassemble them with dis, then tweak the offending C library routines (popen, system, and possibly fork, exec, pclose?) to fix it. Problem is I don't even know if this approach would work and I know nothing about assembly language. The CPU is an M68010 based(I know its ancient) and the operating system is AT&T Unix V.2 rel 1.1 (yes, also ancient). When running S unix calls fail as soon as the process size gets much over 600K - this happens _very_ soon, yet the additional DRAM is nowhere near full. If unix calls are not used the process can grow to at least 3Mbytes without any problems - I presume here the additional memory is being allocated with malloc and the like. My problem only arises it seems if making unix system calls (either via popen or via system). I believe these are checking the value of MAXMEM (in param.h) and spitting the dummy even though there is actually enough DRAM available. So - How can I get around this? Do I need to tweak the assembly for the offending library routines? Is there another way? What should I look for in the assembly code? I hope this is an appropriate place to post this - don't know much netiquette, but would be grateful for any illumination anyone might provide. Thanks for listening, Paul Fisher. (micprf@latvax8.lat.oz.au).
henry@utzoo.uucp (Henry Spencer) (05/10/90)
In article <439@latvax8.lat.oz> MICPRF@latvax8.lat.oz writes: >My problem is this - how do I stop unix system calls from failing >due to lack of space when made from a large process.... This is almost certainly a kernel limitation, not something enforced by the C library. You need to talk to either your system supplier or someone who knows what's going on in your particular flavor of Unix kernel. It could be a dozen things. I've redirected followups away from comp.lang.c. -- If OSI is the answer, what is | Henry Spencer at U of Toronto Zoology the question?? -Rolf Nordhagen| uunet!attcan!utzoo!henry henry@zoo.toronto.edu