Date: Wed, 12 Jul 95 16:58:43 -0400 From: "Shawn M. Carey" <smcarey@mailbox.syr.edu> To: freebsd-hackers@freebsd.org Subject: shmget(2) broken in 2.0.5? Message-ID: <9507122058.AA19034@kong.syr.edu>
next in thread | raw e-mail | index | archive | help
Hello,
I have recenlty started porting a pair of apps that use shared
memory for IPC over to FreeBSD 2.0.5. Note that these apps worked very
well under 1.1.5 (with the addition of a homemade ftok()), but under 2.0.5
shmget() seems to be trying to allocate more shared RAM when you ask it
for an ID by specfying an already existing key. Here's that call from the
parent process that allocates the shared RAM:
(gdb) p *ShmKey
$1 = 5944
(gdb) p *Size1
$2 = 262176
ShmID = shmget(*ShmKey, *Size1, 0x1ff|IPC_CREAT|IPC_EXCL);
(gdb) p ShmID
$3 = 851968
Coincidentally, if I try to do "ipcs -m" at this point, ipcs seg faults.
But if I do a plain "ipcs", it reports the memory as follows:
bandit.290% ipcs
Message Queues:
T ID KEY MODE OWNER GROUP
Shared Memory:
T ID KEY MODE OWNER GROUP
m 851968 5944 --rwarwarwa s_carey rtaiprop
Semaphores:
T ID KEY MODE OWNER GROUP
The child gets the key passed to it via argv[], and from that it figures
out what the ID is:
(gdb) p *ShmKey
$1 = 5944
(gdb) p *Size1
$2 = 262176
ShmID = shmget(*ShmKey, *Size1, 0x1ff);
(gdb) p ShmID
$3 = -1
Maybe I'm doing something wrong here? My experience with SysV IPC is
admittedly lacking. This used to work with 1.1.5, and continues to
work on other platforms (DG/UX), so I suspect I've found a bug. Has
anyone else ran into this?
Thanks,
-Shawn Carey
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9507122058.AA19034>