Subject: kern/8239: vm problem with fork()
To: None <>
From: None <>
List: netbsd-bugs
Date: 08/19/1999 11:10:55
>Number:         8239
>Category:       kern
>Synopsis:       vm problem with fork()
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people (Kernel Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Aug 19 10:20:01 1999
>Originator:     Paul Goyette
|   Paul Goyette  | PGP DSS Key fingerprint:  | E-mail addresses:     |
| Network Engineer|  BCD7 5301 9513 58A6 0DBC |    |
| & kernel hacker |  91EB ADB1 A280 3B79 9221 | |
>Release:        current as of 8/14/99 (1.4J)<NetBSD-current source date>
System: NetBSD 1.4J NetBSD 1.4J (PC1) #11: Sat Aug 14 08:23:24 PDT 1999 i386

	Problem observed using the amcheck program (part of the
	amanda-server-2.4.1p1 package); not yet reproduced with 
	simpler example...

	Program runs setuid root.  Allocates a data structure
	using malloc(), and stores a value into the structure
	(iti's the fd number returned from a socket() call).

	Program then fork()s two new processes.  New process 1
	erases and frees the data structure allocated by the
	parent process.  New process 2 attempts to use the value
	stored into the data structure, and finds that the socket 
	fd number is now zero!

	Main program then waits for both fork()ed processes to
	finish.  Inserting printf() in main process shows that it,
	too, sees a zero value within the data structure.
	Install and configure the amanda-server package.  Then try 
	to do a "amcheck <config>" command.
	Workaround for amanda's amcheck is to remove the line in
	amcheck.c routine start_server_checks() so as not to call
	amfree(msg).  But this does not fix the underlying kernel