First of all, you are right. This problem has nothing to do with GCC. It
started out as a libc or librtl problem, which is probably handled more
appropriately on another list or forum. Now it has become an obscure
Linux problem. Not sure where to turn to.
Having said this, thanks for the tip about umask(). This allowed me to
change the access privileges to the shared memory.
Regrettably, my first experiment was with unmask(777) which did horrible
things. Now mmap() throws a "Permission denied" error, even though
/dev/shm/shared has 777 privileges. It appears to be from detached
memory blocks that do ipcrm cannot remove:
ts7500:~# ipcs -m
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x75000000 0 root 0 4096 8
My guess is the segment cannot be released because it is attached to 8
processes and I cannot find them to kill them. Nor do they release the
segment on terminating. I have tried rebooting and depowering +
rebooting, all to no avail. The controller always comes back with
nattach = 8.
Thanks,
RF
On 12-09-11 10:12 AM, Jonathan Wakely wrote:
On 11 September 2012 17:23, Bob Furber wrote:
On 12-09-07 04:08 PM, Jonathan Wakely wrote:
On 8 September 2012 00:03, Bob Furber wrote:
Why is the client capable of accessing shared memory when executed by
root
and not able to, when executed by a user?
This doesn't sound like it has anything to do with GCC.
After a lot of experimentation, I think the problem lies in shm_open().
So nothing to do with GCC then.
The following code generates a /dev/shm/shared with -rw-r--r-- access
privileges, making it inaccessible to others, even though the mode is set to
rw-rw-rw-:
shmfd = shm_open( shm_name, // shared memory block with this "/name"
O_CREAT, // Create if not already there
0666 ); // with these access privileges
It sounds like your process has a umask of 0022.
