Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!aurora!labrea!decwrl!pyramid!prls!mips!roger
From: roger@mips.UUCP (Roger March)
Newsgroups: comp.sys.apollo
Subject: SET_SBRK_SIZE() considered brain damaged ...
Message-ID: <682@obiwan.UUCP>
Date: Tue, 15-Sep-87 17:27:34 EDT
Article-I.D.: obiwan.682
Posted: Tue Sep 15 17:27:34 1987
Date-Received: Fri, 18-Sep-87 00:49:34 EDT
Lines: 58
Keywords: sbrk(), fork(), Domain IX, bsd4.2, heap insanity ...


	  Argh! I hate it when I have to drag one of my programs to an
	Apollo and "set_sbrk_size()" is right at the top of my list of
	vomit inducers. I mean, give me a break, the default heap size
	is 256Kb, go above that and its segment fault city. RETCH! Not
	only do I have about zero programs which can live in such cramped
	quarters, but I've had UNIX utilities ("sort" I think) which I
	believe crashed due to running out of heap space. What is it
	about Domain-IX/AEGIS which keeps "sbrk()" from just allocating
	some more turf when it runs out of heap space up to the virtual
	memory limit?
	  Enough (justiified) flaming, onto an interesting side effect
	of "set_sbrk_size()". My usual technique for getting a man sized
	heap space is to put something like this in "main()":

		#define	MB	* 1024 * 1024
		main()
		{
		  static int vm[] = { 7MB, 48MB, 120MB };
		  int i;
		  /*
		   *	Reset the heap size until we can allocate.
		   */
		  for (i = sizeof(vm) / sizeof(int); i--;){
		    set_sbrk_size(vm[i]);
		    if (sbrk(0) >= 0)
		      break;
		  }
		  ...	/* real stuff follows */

	Which pretty much sets the heap at the virtual limit for the
	machine the program is run on. This has worked fine for a long
	time. But now I want my program to "fork()". Yeah, real tough
	code like:

		if (pid = fork()){
		  ...	/* more real stuff */

	and the "fork()" fails. Good old "perror()" says "I/O ERROR";
	pretty informative huh. And I was a real nice guy and the heap
	is virtually empty at the point I "fork()", so it doesn't seem
	possible it barfed because it didn't have space to replicate
	the data areas.
	  Its appears to be "set_sbrk_size()" related in that if I just
	hardwire the heap space to:

		set_sbrk_size(4MB);

	everything works just fine. Does anyone have clues to why
	"set_sbrk_size()" breaks "fork()"? What is it about Apollo's
	memory management that spawned an abortion like "set_sbrk_size()"?
	And if I'm doing something stupid which makes this problem go
	away let me know and you can even call me nasty things (oh yeah,
	don't stop!). 
-- 
-your friendly neighborhood Rogue Monster                     roger@mips.com
UUCP: {decvax,ucbvax,ihnp4,hplabs,sun,ames,prls}!decwrl!mips!roger
USPS: MIPS Computer Systems, 930 Arques, Sunnyvale, CA 94086, (408) 991-0220