Xref: utzoo unix-pc.general:3468 rec.games.hack:4617
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!rutgers!dptg!mtunb!jcm
From: jcm@mtunb.ATT.COM (was-John McMillan)
Newsgroups: unix-pc.general,rec.games.hack
Subject: Re: Large programs core dumping upon execution
Summary: Sporadic problems loadign programs VS. Shared Memory
Message-ID: <1586@mtunb.ATT.COM>
Date: 3 Aug 89 14:09:59 GMT
References: <211@comhex.UUCP> <978@rush.cts.com>
Reply-To: jcm@mtunb.UUCP (John McMillan)
Organization: AT&T ISL Middletown NJ USA
Lines: 43

In article <211@comhex.UUCP> sysop@comhex.UUCP (Joe E. Powell) writes:
>Has anyone else ever noticed that very large (over 300K) files
>sometimes tend to core dump when they are invoked?  They usually
>work fine, but every now and again, the program will just refuse
>to start up.  Is it just me or have other people had this happen?

A final (HAhahaha...) muttering from me on this:

1) While I posted (or E-mailed) earlier that this sounds like classic
	outta-SWAP trouble, another possibility occured to me.

2) Until approx. the 3.51C kernel, there was an error in the
	'getcontext()' code.  Despite mis-leading COMMENTS, the code
	failed to properly change context between two processes.

	Specifically, if the OUTGOING process had SHARED MEMORY [SHM],
	it was left mapped-in in the 'MMU'.  This caused gross pain
	when that SHM was at a low enough address that another
	process attempted to use the same Virtual Address [VA] space.

	Since the 'MMU' indicated the page was PRESENT, the new
	process didn't fault-in its own page on 1st access -- ie.,
	start-up, usually.  Since it's typically difficult to
	execute another programs shared data, death by illegal-
	instruction was common if the new program had a LARGE TEXT
	image.

	The error remained as long as it did because:
	a) the coincidence of low-VA SHM & concurrent large TEXT process
		is rare;
	b) the kernel code was 'correct' and the comments were
		mis-leading: the CONCEPT was flawed because the
		stated process was not 'in-context' when the code
		was executing;
	c) the entire, creaking/ancient VM base for the 3B1 -- based
		on some Berkeley model -- is obscure and barely
		even patchable due to its anomalies.

In brief, there are SOME cases where program start-up failures may
	reflect the above problem.  I presume IPCS(1) would indicate
	if you've SHM in use, but WHERE it's mapped is another Q.

john mcmillan	-- att!mtunb!jcm