Large programs core dumping upon execution

[was-John McMillan]

In article <211 at comhex.UUCP> sysop at 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