From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74984 invoked by alias); 9 Apr 2015 07:58:22 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 74972 invoked by uid 89); 9 Apr 2015 07:58:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 X-HELO: calimero.vinschen.de Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 09 Apr 2015 07:58:21 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id F352CA80A70; Thu, 9 Apr 2015 09:58:18 +0200 (CEST) Date: Thu, 09 Apr 2015 07:58:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: Shared memory handling for mixed C/FORTRAN program Message-ID: <20150409075818.GP2819@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <1999567694.2259208.1428493743005.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8cpS+6Cx+xtICsjy" Content-Disposition: inline In-Reply-To: <1999567694.2259208.1428493743005.JavaMail.yahoo@mail.yahoo.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-04/txt/msg00129.txt.bz2 --8cpS+6Cx+xtICsjy Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2284 On Apr 8 11:49, Christoph Weise wrote: > I am porting to cygwin a program in FORTRAN/C that relies on C > routines to create a shared memory region allowing various independent > FORTRAN routines to share data. Program compiles and runs ok on Linux > with g77/gcc compilers. I am compiling on cygwin 1.7.33-2(0.280/5/3) > with gfortran/gcc (4.8.3). >=20 > One C routine creates the shared memory section of a user-defined > size. This seems to work just fine, although I had to add two lines to > the sys/shm.h file: >=20 >=20 > #define SHM_R 0400 /* or S_IRUGO from */ > #define SHM_W 0200 /* or S_IWUGO from */ These are non-standard Linux extensions. You should use the normal permission bits from sys/stat.h, like S_IRUSR, S_IWUSR, etc. > The shm library functions seem to return reasonable info (page size > and address, for removal of the shm section). >=20 >=20 > Each FORTRAN routine then calls a C routine to find the shared memory, > with a C routine returning pointers to two positions in the section > intended for different kinds of data: >=20 >=20 >=20 > #define PAGESIZE 1024 PAGESIZE on Cygwin is not 1024, and the right value to use for XSI SHM is SHMLBA (=3D=3D 64K on Cygwin) > int findshm(char**pptr, /* Address of the parameter pointer */ > float**cptr) /* Address of the data pointer */ >=20 > ....calls to shm library functions .... >=20 > shmaddr =3D0; p =3Dshmat(shmid,shmaddr,(SHM_R |SHM_W)); *pptr =3Dp; *cptr > =3D(float*)(p +PAGESIZE); return npages; >=20 >=20 > The calling FORTRAN code looks like this: >=20 > integer pptr,cptr integer npages npages =3Dfindshm(pptr,cptr) >=20 > Although the total size of the created memory section npages is ok, > the amount of memory following cptr is too small on cygwin (but not in > Linux) and the program crashes for larger datasets with >=20 > Program received signal SIGSEGV:Segmentationfault -invalid memory > reference. Does shmat actually return a non-NULL value? Are you running cygserver? Did you check if it works from plain C? If not, do you have a simple testcase in plain C? Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --8cpS+6Cx+xtICsjy Content-Type: application/pgp-signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVJjEaAAoJEPU2Bp2uRE+g0FoP/3JIFgpGPElybyk6ZvuBRjDA 3d0aawgQeejY5n9Rx1w8gZZ997hAbhUrlgZwjEvtMawa6rk7gwdcE3VwW5vw4+nb HmhRMrxibU1tscb0aAz6wkbolLWc3oVZZqSCkn44yapbel1fuYnekwg1tH3miWQK eFLkQdAZx7M9XXZBckt8dI/bsAZKhYj4igEMnFPutwPKRpHmAEio40+HB+T8ws8d 2T1tzCtElo08/b8GaPIB1NDWANRMB1vE9CQgQ3onopg1ndggyf1OLAlGlkY4H6Z7 emeru/gBzUpBRSnUq9OQkJt/dAebRZKxFd1MVu5GAit2hSi0tO9HDIbrzHaKJBaP IWpO017ydojTWuIOHt2zQkmTP7uon4BUin0UvTYbs0wHerLMQ1KmwyfSiyebTLwr t9CKUEc2gj+nk6ruNoORCAb/sP2rQY4As64dzlOAUjDVRdi8PwwYf3JFTr0RPQy+ gq+83FdT21dl1k2DGH7sAX8STBWz6toFa7abgt1AftW1XsUvdD46ixJwXCXjiLnv Y3bi9ueWG9BzW52QcAUaOrVXO5HeeWBlVDXuNTd/MwUrOnNxigeq6mt0lN8goZWb 9J0qliOPZKIzXjheu6Ml/r+SVHb/1GYO5eCzKZqBRDSfAkgmNjEz/FEHMf30odcB 5inhmMc7UfxiqKRzxLp+ =FA7m -----END PGP SIGNATURE----- --8cpS+6Cx+xtICsjy--