Oyvind, > That's expected. Since shared memory doesn't belong to a specific > process, the kernel will not know when to clean up the memory.
When I was using libmm, I never had this problem. I could crash my software a dozen times in an hour and still be able to get a fresh segment. I guess that's why I didn't expect it in APR; my understanding was that APR's shared memory system was grown out of libmm. I can understand the kernel not knowing that the memory is no longer used if there was still a straggler process hanging onto it. But when there are no processes left to access it, why does this continue to happen? If memory doesnt belong to any process at all, shouldn't it be, well, free? Regular memory works this way, files and filehandles work this way, why doesn't shared memory? Is it really that hard to keep a count of running processes that have opened a shared memory segment? And if this is a deficiency of the linux kernel, shouldn't APR, as a Portability library, be ready to handle this quirk and clean up for you, either automatically, or via a portable equivalent to ipcrm, etc? Also, there's a second symptom that I've started to notice. Because of this bug, I have to change my starting path each time. After 4 or 5 crashes, I don't only have to change directories, but _partitions_ as well, to get a new good segment. This really concerns me, because it seems to indicate that it's possible for two processes backing their shared memory off of different files in different directories on the same filesystem to conflict. What's the point in specifying a path if that path doesn't contribute to the uniqueness of the shared memory segment? > | "apr_shm_create(&rv, 880, ".../libbtt.shm", pool) failed: File exists" > My guess is that shm_open thinks the file already exists because the > shared memory was not cleaned up properly (although ".../libtt.shm" is a > bit odd relative path). It was actually /sanity/tr4/libbtt.shm, I just stripped the rest off because my path naming convention is silly. :) - Tyler
