delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2015/04/11/06:19:14

X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
:list-unsubscribe:list-subscribe:list-archive:list-post
:list-help:sender:date:from:to:subject:message-id:reply-to
:references:mime-version:content-type:in-reply-to; q=dns; s=
default; b=eBRsQbx+Tm9YHHZcCZkD32fhTXQTDhQsIz6WdFuj6PJ2ttXJVU0S/
ngRVXD2VfWLbnHHSczWNyq86iGi532dFbNOMYDkLEiV7qKsYrUPY6qV8KW+UJvoq
DMW1f9vjzE8EEQ5Mllj5UrEuVHObhj79FEX8MuNOhMpQA5PWbvdnhc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
:list-unsubscribe:list-subscribe:list-archive:list-post
:list-help:sender:date:from:to:subject:message-id:reply-to
:references:mime-version:content-type:in-reply-to; s=default;
bh=yzwSn1F2Aw+qXYdJFn/fnE6/hmM=; b=KYzYD0SllXALXzM4Cnfiq8m09KeH
8fulOBZ2JXT+W2JbOy1xBjNbhR4m+uZKBvTpvFEUQN2QAA8H9YN2d65CHYJjLRQY
UiK1DON4IihRAAb5gdPnsGp0OjoRCbtHdo+AA5QKVZYZmxVTsulst8bgW976REvs
jRBPDkKojNIuh3A=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.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
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,UNSUBSCRIBE_BODY autolearn=no version=3.3.2
X-HELO: calimero.vinschen.de
Date: Sat, 11 Apr 2015 12:18:51 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Shared memory handling for mixed C/FORTRAN program
Message-ID: <20150411101851.GF19111@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <1999567694 DOT 2259208 DOT 1428493743005 DOT JavaMail DOT yahoo AT mail DOT yahoo DOT com> <1194341851 DOT 758458 DOT 1428704443750 DOT JavaMail DOT yahoo AT mail DOT yahoo DOT com>
MIME-Version: 1.0
In-Reply-To: <1194341851.758458.1428704443750.JavaMail.yahoo@mail.yahoo.com>
User-Agent: Mutt/1.5.23 (2014-03-12)

--K/NRh952CO+2tg14
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Apr 10 22:20, Christoph Weise wrote:
> >PAGESIZE on Cygwin is not 1024, and the right value to use for
> >XSI SHM is SHMLBA (=3D=3D 64K on Cygwin)
>=20
> Setting PAGESIZE to SHMLBA creates problems elsewhere in the program
> (then PAGESIZE is too big for the program to handle, a problem I have
> yet to debug) so only unless there is no workaround (please see below)
> I'd like to avoid trying to use SHMLBA for the time being.

The PAGESIZE is an OS-specific value.  If you set it to some arbitrary
value and use it for your own purposes it's ok, but if the application
expects the OS to follow its lead, you'll run into problems.

> Regardless of the choice of PAGESIZE, only a total of 4kB can be
> stored sequentially in the shared memory section handed by shmat. If I
> try to write more than this number of bytes to the shm section the
> program crashes.=20

Not that I know of.

> > Did you check if it works from plain C?  If not, do you have a
> > simple testcase in plain C?
>=20
> I modified the first C utlity, which sets up the shared memory
> section, to use the addresses it receives from shmat to try to write
> as much data as possible into the section. I could read/write to the
> full shm section from within that utility.=20

Which means, the memory has been allocated the right size.

> I also modified a second C routine which looks for the memory section
> and returns addresses into the shm section. When attempting to
> read/write within that second routine the program crashes when
> accessing addresses more than 4 kB from the start of the shm section.=20

Is that inside the same executable?

> I found this=20
> https://www.cygwin.com/ml/cygwin/2009-01/msg00492.html
> and links from there, which suggest that this 4kB "barrier" is probably r=
elated to cygwin's memory handling.=20

That has nothing to do with it.  It's just a question I replied to.
Cygwin always returns memory in 64K chunks because that's what the
underlying OS does.

Unless the OS is asked to return shared memory backed by a file.  In
this case it returns memory ending on a 4K boundary.  That's weird, but
Cygwin has code trying to workaround this problem.  But that doesn't
affect shmat.

> If this is in fact a likely source of the problem,

No, it isn't.  If you can provide a simple testcase in plan C which
allows to reproduce the issue with minimal code, I'd take a look into
the issue.


Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--K/NRh952CO+2tg14
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJVKPULAAoJEPU2Bp2uRE+gXAsP/3ITsOaLl7mz9MI+byiVFy8l
KSKPIriBHlarK6qtYP88yPhhfGLYP8lo9FqBq8KpjRXKcHs/3lAuaHA+foyXIk33
jVg4SoTJbGjGZyICj6K4j7Hxr6xz0AZlokxjsu80aHaksgmb2J2auEqUj2pclMLP
3oRH1ANMTS1vLpxQKKBgoamUTjrlKpjpau6I3trXtHwVaa9P2bKQoTPJ4WNhjrFy
Re1cjvRObScGhuAZ6TfSsRdci7tzc2PprO0Cg2ZbeIQjL9b+q9he+YtAPl0Lm4ZW
vTY2EQrtbLYu+jlzMvOJNI6cdGTERr4AfVeXSHKWLKP4U0KqJgSHrPyAt/COBXqe
KIAz3xoMqLggItFI32IXeViKsjsMqLYrmp65IZg1lVUozTx8CKYxLkwtQQpw0A4H
fJerX5AXf2H4XdQXJpLuWDweIgCzLuhRyKD1jAgien5uueyi7T3IWsDga33sEmsk
qBGQd30JBQ8F0oCXSCXLsnMjJyKxOXPScd/eiXXXaYRRNHZCBDOdj4xNWRzttVTm
96Z3vuYOZrJgaRaBfZym1l75mHu4ZhTZfBvQRBsnlwrtlTv0Lf4M+6w485uEZhfx
65ciGTUF+O4emzE3LnmCAvpm5zTz2QXguQnwBLRw9eID14IKqI+Pv8CJqTfofrzU
s0rD8D1+g4DV2NRKcI47
=C6rE
-----END PGP SIGNATURE-----

--K/NRh952CO+2tg14--

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019