>Number:         275
>Category:       kern
>Synopsis:       With a (slightly) fixed shmat(2) (see previous bug-report), it gives ENOMEM
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    gnats-admin (Kernel Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jun  3 13:35:02 1994
>Originator:     Thorsten Lockert
>Organization:
SigmaSoft, Th. Lockert
>Release:        current
>Environment:
	
System: NetBSD gandalf.bbb.no 0.9B GANDALF#3 i386

>Description:
	With shmat(2) fixed to avoid the EMFILE error return due to initialization
	problems, it still fails.  Now with ENOMEM.  I'm not sure as of now if it
	is shm_find_space or vm_mmap that fails, but from looking at the code it
	is very unlikely that it is shm_find_space.  It might, however, be due to
	the code in shm_find_space not returning a usable vm address in the address
	space of the process, I've not investigated that far yet.

	This makes it impossible to use eg. the shared memory extension of X.
>How-To-Repeat:
	Change shmat(2) to initialize the shmid's stored in the p->p_vmspace->vm_shm
	map to -1 or the code to expect (and store) 0 for free entries.  Try to
	attach a shared memory segment
>Fix:
	Unknown.
>Audit-Trail:
>Unformatted:


------------------------------------------------------------------------------