X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Message-ID: <ba40711f0711050443h6733c234o3c2d4a78f410360d@mail.gmail.com>
Date: Mon, 5 Nov 2007 07:43:43 -0500
From: "Lev Bishop" <lev DOT bishop AT gmail DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: cygwin stable and cvs snapshot - fork() bug
In-Reply-To: <20071105102147.GI31224@calimero.vinschen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
References: <C0ED6A2866953E4487135B5DFCFF89A501C04512 AT hmsx21 DOT pnet DOT ch> 	 <4721DFCC DOT 8070100 AT cygwin DOT com> 	 <C0ED6A2866953E4487135B5DFCFF89A501C048D6 AT hmsx21 DOT pnet DOT ch> 	 <20071029083512 DOT GA4224 AT calimero DOT vinschen DOT de> 	 <C0ED6A2866953E4487135B5DFCFF89A501C04A65 AT hmsx21 DOT pnet DOT ch> 	 <4725D656 DOT 5090303 AT cygwin DOT com> 	 <C0ED6A2866953E4487135B5DFCFF89A501C375CD AT hmsx21 DOT pnet DOT ch> 	 <ba40711f0710311126m6ae84f5ci4e7e481869ed63a7 AT mail DOT gmail DOT com> 	 <20071101095835 DOT GG31224 AT calimero DOT vinschen DOT de> 	 <20071105102147 DOT GI31224 AT calimero DOT vinschen DOT de>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id lA5Ci6sQ015045

On 11/5/07, Corinna Vinschen  wrote:
> On Nov  1 10:58, Corinna Vinschen wrote:
> > On Oct 31 14:26, Lev Bishop wrote:
> > > $ cat lev.c && gcc -o lev lev.c -Wall -Wextra && CYGWIN=server ./lev
> > > #include <stdio.h>
> > > #include <unistd.h>
> > > #include <sys/shm.h>
> > >
> > > int main(void)
> > > {
> > >         int shmid;
> > >         if ((shmid = shmget(IPC_PRIVATE, 100,IPC_CREAT | 0600 )) < 0 ||
> > >                 !shmat(shmid, NULL, 0) ||
> > >                 shmctl(shmid, IPC_RMID, NULL) < 0)
> > >                 puts("problems with shm!");
> > >         fork();
> > > }
> > > lev.c: In function `main':
> > > lev.c:13: warning: control reaches end of non-void function
> > >       3 [main] lev 1924 c:\Documents and
> > > Settings\Lev\Desktop\mpd-0.13.0\lev.exe: *** fatal error -
> > > MapViewOfFileEx (0x3E0000), Win32 error 6.  Terminating.
> > >     124 [main] lev 5076 fork: child 1924 - died waiting for dll
> > > loading, errno 11
> >
> > Thanks for the testcase.  I'm surprised that nobody experienced this
> > problem before.  Sorta holiday here, so I'll look into it next week.
>
> 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.

Lev

--
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/