mckay@courageous.ecn.purdue.edu (Dwight D. McKay) (04/26/89)
I have another problem which the Sun Hotline has not given me any response
on after two calls:
The Problem:
------------
On a Sun 4/110, if you type "unlimit stack" and then any other
command, you will end up in the monitor. Not good.
Questions:
----------
* Has anyone else seen this?
* Is there a fix for this? (Before you blithely say, "install the
4.0.X patches, let me tell you that we're a source license site. Binary
patches don't do us any good as they usually overwrite our own fixes. If
you can tell me which patch or better still what the source change needed
is, that'll help a lot! Better still would be source to "point-point"
releases, but that's another story...)
--Dwight D. McKay, ECN Workstation Software Support
--Purdue University, Engineering Computer Network
--Office: MSEE 104f, Phone: (317) 494-3561
--ARPAnet: mckay@harbor.ecn.purdue.edu, Usenet: ...rutgers!pur-ee!mckayguy@uunet.uu.net (Guy Harris) (05/08/89)
> On a Sun 4/110, if you type "unlimit stack" and then any other >command, you will end up in the monitor. Not good. There are many wonderful ways of watchdogging a 4/110, apparently; I think some of them may be fixed in some dot-dot release. However, even on a machine other than a 4/110, if you type "unlimit stack" and then almost any other command, you'll be in for a surprise. The SunOS "mmap" implementation, when not given an indication of where to place the object being mapped in (i.e., when you give it a null pointer as the address to which the object should be mapped, and don't use MAP_FIXED), has to choose *some* place to put it. Well, it starts putting things right below the stack limit, and moves down from there; that keeps it from colliding with the heap as it grows up, or at least delays the collision as long as possible. If you unlimit the stack, there isn't any "right below the stack limit" any more, since there's no stack limit, so it just has to throw up its hands in despair. The run-time loader used for dynamically-linked programs will, when it maps in shared libraries, not tell the kernel where it should put them; I think the code in "crt0.o" that maps in the run-time loader does so as well. Thus, if you have no stack limit, none of these shareable images can be mapped in, and thus you cannot run any dynamically-linked images.... Since shareable images are relocated at run time (if compiled with "-pic", not much relocation is needed, which cuts down on the number of pages copied-on-write), proper operation of those images is not dependent on where they're put in the address space. Thus, while you can't unlimit the stack and have dynamically-linked programs run, you can provide any finite limit (that leaves room for the images, and anything else such as frame buffers, etc., to be mapped in) and have the programs still work.