On 12/09/12 05:45, Bob Furber wrote: > 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: Did you read umask(2) ? If you wanted to remove the umask(), you'd call umask(0). The umask is used to specify the permissions that should *not* appear in the new file. > > 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 Killing the processes will not remove the segment (this interface is not very consistent with other parts of the system). You can use ipcrm(1) to delete the segment. Rebooting the system does remove the existing shared memory segments. If you're seeing it on reboot, some program run on boot is recreating it.
