Path: utzoo!utgpu!news-server.csri.toronto.edu!torsqnt!jtsv16!gerry
From: gerry@jts.com (Gerry Roderick Singleton )
Newsgroups: comp.unix.wizards
Subject: Re: shmat() system call? (A related question)
Message-ID: <1990Aug17.170733.3807@jts.com>
Date: 17 Aug 90 17:07:33 GMT
References: <27@astph.UUCP> <187@n4hgf.Mt-Park.GA.US> <THOMAS.90Aug16123252@uplog.uplog.se>
Organization: JTS Computer Systems Ltd.
Lines: 114

In article <THOMAS.90Aug16123252@uplog.uplog.se> thomas@uplog.se (Thomas Tornblom) writes:
>In article <187@n4hgf.Mt-Park.GA.US> wht@n4hgf.Mt-Park.GA.US (Warren Tucker) writes:
>
>   In article <27@astph.UUCP> jeff@astph.UUCP (8592x2) writes:
>   >
>   >Question concerning the shared memory attach call:
>   >
>   >I am writing a shared memory allocation manager for a multi-user
>   >database.
>   >I need to know if additional attaches by other processes will be
>   >guaranteed to return the same address as that the first process
>   >was returned.
>
>   To be sure, specify the attach address, regardless of what the FM says.
>   Make a small program that passes 0 for the address and see what it
>   returns.  Then, use that value hardcoded, possibly #defined for each
>   arcitecture you plan to run the program on.
>
>[example deleted]
>
>This is not guaranteed to work. Typically the kernel allocates the addresses
>depending of the memory layout of the running process.
>
>Our sysV.2 68k kernel uses the current end of bss rounded up with some
>constant as the lowest base for shm. It also checks that the segment doesn't
>overlap into the stack or other shared memory segments.
>
>If you must have the same addresses between the processes (which is nice for
>pointers and stuff) I'd pick some high constant address, say 0x[48c]0000000
>or so that isn't likely to map onto anything on the architectures you're using.
>
>Thomas

Since we're talking about attaching the same memory segment to multiple 
process, I want to add a gotcha to the discussion and ask for help on my
part of the problem.  The problem is simply that under SunOS 4.1 you can
not release a segment, using shmdt(2), that was attached by shmat(2) as
read/only.  I contacted my Sun people with the bug who told me to place a
service call.  I am in the process of doing this but would sure like any
solutions/work arounds that you wizards have on hand.

Here's what I sent Sun:
Subject: SunOS 4.1 / Shared Memory Bug
Status: OR

The following example demonstrates shmdt(2)'s inability to release an R/O 
segment.

Please e-mail your solutions and I will summarize to the list.

Symptom:  shmdt() always fails if the segment was attached read-only with
	shmat().

Example Program:

#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/shm.h>
#include <stdio.h>
  extern char *shmat();

#define PERMS 0777
#define SHMSIZE 10000

main()
{
    char *shared_data;
    int shmid;
    key_t key;
    int shmflag;
    int ret;
    
    key = getpid();
    
    shmid = shmget( key, SHMSIZE, IPC_CREAT | PERMS );
    if( shmid < 0 )
      exiterr( "error shmget ");
    
    printf( "shmid %d\n", shmid );

/* This is the culprit.  If SHM_RDONLY is left off it works. */
    shared_data = shmat( shmid, 0, PERMS | SHM_RDONLY );

    if( shared_data == NULL )
      exiterr( "error shmat");

    ret = shmdt( shared_data );

    if( ret < 0 )
      exiterr("error shmdt ");

    exit(0);
}

exiterr(s)
     char *s;
{
    
    fprintf( stderr, "%s\n",s );
    exit(99);
}


Regards,
ger
--
G. Roderick Singleton, System and Network Administrator, JTS Computers 
	{uunet | geac | torsqnt}!gerry@jtsv16.jts.com
Be careful of reading health books, you might die of a misprint.
		-- Mark Twain
-- 
--
G. Roderick Singleton, System and Network Administrator, JTS Computers 
	{uunet | geac | torsqnt}!gerry@jtsv16.jts.com