Re: Shared memory handling for mixed C/FORTRAN program

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

[-- Attachment #1: Type: text/plain, Size: 2599 bytes --]

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 (== 64K on Cygwin)
> 
> 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. 

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?
> 
> 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. 

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. 

Is that inside the same executable?

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

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

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]