X-Recipient: archive-cygwin@delorie.com X-Spam-Check-By: sourceware.org Date: Mon, 5 Nov 2007 14:29:38 +0100 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: cygwin stable and cvs snapshot - fork() bug Message-ID: <20071105132938.GO31224@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <4721DFCC.8070100@cygwin.com> <20071029083512.GA4224@calimero.vinschen.de> <4725D656.5090303@cygwin.com> <20071101095835.GG31224@calimero.vinschen.de> <20071105102147.GI31224@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com On Nov 5 07:43, Lev Bishop wrote: > On 11/5/07, Corinna Vinschen wrote: > > Ouch, ouch, ouch. shmctl(IPC_RMID) closed the handle to the shared > > memory, but neglected to remove the actual mappings as well as the > > bookkeeping structure. The result is that after a fork the child thinks > > there are still mappings which have to be duplicated into its own > > memory. But the handle has already been closed in the parent, so the > > MapViewOfFile call fails with "invalid handle". > > > > Unfortunately not many applications use shmctl(IPC_RMID) before creating > > a child process since usually the shared memory is meant to be... well, > > shared. That's why this didn't crop up more often, obviously. > > Are you sure that you're interpreting IPC_RMID correctly? My > understanding is that you can still share the memory until you > actually remove the mapping. (Sort of like how you can unlink() a temp > file immediately after you open it, and continue to use it). I assumed > this was the reason for the create-map-remove pattern used by mpd. > > From the linux man page: > IPC_RMID Mark the segment to be destroyed. The segment will only > actually be destroyed after the last process detaches it > (i.e., when the shm_nattch member of the associated strucā > ture shmid_ds is zero). The caller must be the owner or > creator, or be privileged. If a segment has been marked > for destruction, then the (non-standard) SHM_DEST flag of > the shm_perm.mode field in the associated data structure > retrieved by IPC_STAT will be set. Well, when I created the patch, I had read the SUSv3 man page http://www.opengroup.org/onlinepubs/009695399/functions/shmctl.html. It says something different: IPC_RMID Remove the shared memory identifier specified by shmid from the system and destroy the shared memory segment and shmid_ds data structure associated with it. IPC_RMID can only be executed by a process that has an effective user ID equal to either that of a process with appropriate privileges or to the value of shm_perm.cuid or shm_perm.uid in the shmid_ds data structure associated with shmid. OTOH, the implementation within cygserver is more along the lines of the Linux manpage. Oh well. I guess I'll have a look into implementing it more Linux-like. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/