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
