idall@augean.OZ (Ian Dall) (06/29/87)
On my SysV.2.2 system ( National Semiconductors port for the ICM-3216 )
the ulimit(2) system call seems to misbehave. The man entry says it
returns the maximum break value possible. For this system 8MB is reasonable
since it has 16MB virtual address space half of which is stack space.
Sure enough ulimit initially does return 8MB. However, after doing a brk(n)
where n is anything greater than 20000 hex, ulimit returns 20000 hex. If n
is less than 20000 hex it returns 8MB.
This is illustrated by the staggeringly useful program as follows:
#include <errno.h>
main(){
long foo;
extern long ulimit();
extern char *sbrk();
extern int brk();
char *foop;
foo = ulimit(3, 0l);
printf("Makimum break value %d (%X)\n",foo , foo);
foop = (char *) 0x7E0000;
printf ("Set break value to %d (%X)\n",foop,foop);
brk(foop);
foo = ulimit(3, 0l);
printf("Makimum break value %d (%X)\n",foo , foo);
foop = (char *) 0x50000;
printf ("Set break value to %d (%X)\n",foop,foop);
brk(foop);
foo = ulimit(3, 0l);
printf("Makimum break value %d (%X)\n",foo , foo);
foop = (char *) 0x18000;
printf ("Set break value to %d (%X)\n",foop,foop);
brk(foop);
foo = ulimit(3, 0l);
printf("Makimum break value %d (%X)\n",foo , foo);
exit();
}
Which results in:
Makimum break value 8257536 (7E0000)
Set break value to 8257536 (7E0000)
Makimum break value 131072 (20000)
Set break value to 327680 (50000)
Makimum break value 131072 (20000)
Set break value to 98304 (18000)
Makimum break value 8257536 (7E0000)
The question is: Is this a bug or a feature? In the unlikely event that it's
a feature, what is the significance of 20000 hex? If it's a bug, is it
generic to SysV or just this port of it?
Ian Dall
idall@augean.ozjoer@nscpdc.NSC.COM (G. Wiz) (07/01/87)
In article <185@augean.OZ> idall@augean.OZ (Ian Dall) writes: > >On my SysV.2.2 system ( National Semiconductors port for the ICM-3216 ) >the ulimit(2) system call seems to misbehave. >The question is: Is this a bug or a feature? >If it's a bug, is it generic to SysV or just this port of it? > >Ian Dall This WAS a bug in an earlier release. I do not know if it was generic SysV or if it was our port. None the less, it has been repaired. I would like to say that asking the world about alleged bugs in a specific implementation is not the best way to get a resolution (nor is it a nice thing to do). In general, the world does not have the answer to that type of question. It is better to ask the manufacturer directly over the provided support phone line (free to licensed users in U.S.). I realize that you are in Australia. You can email directly to me if you choose not to call, (hours being different here and all). Cheers, -- /****************************************************************************** * * * Joe Rawlings nsc!nscpdc!joer or * * ICM Product Support tektronix!reed!nscpdc!joer * * National Semiconductor Corp. 1-800-222-2433 (outside Oregon) * * Portland Development Center or 629-4414 (inside Oregon) * * * ******************************************************************************/