shared memory not getting freed

I have a program that allocates shared memory for itself and then forks and attaches the same shared memory to the child process. it looks like the shared memory is not getting freed after both the parent and child detach and call shmctl(shm_id, IPC_RMID, NULL), but when I use the command ipcs -m in a shell, all of the IDs I allocated still show up, but show that they are unattached. I'm not sure what more I need to do to free these shared memory segments. any help would be greatly appreciated.

thanks in advance.

Seems like this is the intention:

Quote:

---

from http://fscked.org/writings/SHM/shm-5.html#ss5.3

Shared segments in System V are a bit different than those obtained with BSD's mmap. First of all, while you do need a key for a segment which is usually obtained by running ftok(2) on some file in the filesyetem, System V shared segments exist only in memory. Because of this, System V shared segments must persist after the termination of a process. It is the responsibility of the programmer to ensure that all of his segments are removed from the system, otherwise his memory leaks become system wide.

---

My emphasis.

--
Mats

as I'm sure you read in my original post, I am detaching and calling shmctl() to remove the shared memory. it does not seem to be producing the desired effect. is there anything else that I need to do, in addition to these two operations, to free the shared memory?

And you are doing that in BOTH of the forks?

--
Mats

Quote:

---

Originally Posted by matsp

And you are doing that in BOTH of the forks?

--
Mats

---

yes, I am. according to the docs, this is all that is required, but I still see shared memory not getting freed.

Are you checking return codes for failure?

gg

Quote:

---

Originally Posted by Codeplug

Are you checking return codes for failure?

gg

---

I wasn't but now I am, and now it appears the memory is being freed.... weird... I'll monitor it for a few days and see what happens, but it appears to be working properly now.

one other thing.... is there a way to free the memory without a reboot? or do I just have to accept the lost memory until the next reboot?

See if "ipcrm" helps any.

gg

Quote:

---

Originally Posted by Codeplug

See if "ipcrm" helps any.

gg

---

I tried it, but for every ID I try to remove, it says ipcrm: already removed id (...)

any other ideas?

I'm having a completely new problem with this now...

for some reason, over the last 24 hours or so, it has failed to delete about 60 shared memory segments, all of which say they are still attached, although the program did not report a failure to detach, but rather a failure to free the shared memory after a detach (this behavior is not completely unexpected, as I'd expect it to throw an error when trying to delete a segment that has already been deleted).

I am calling shmdt() and shmctl(shmid, IPC_RMID, NULL) in both processes using the shared memory, so I am really confused about what is going on here. I know there have been many more than 60 connections to the server since then, so it's clearly not doing it for every shared memory segment, but I don't really know what's going on for the ones it's failing to delete.

It's called SHARED MEMORY. If your program deleted the segment when it exited, it would hardly be shared, would it?

This is one of the few resources that does NOT get reclaimed when you exit. Personally, I stay the hell away from shared memory and just use shared memory maps.

Quote:

---

Originally Posted by brewbuck

It's called SHARED MEMORY. If your program deleted the segment when it exited, it would hardly be shared, would it?
This is one of the few resources that does NOT get reclaimed when you exit.

---

did you read any of the previous posts in this thread?

at what point did I say I was allocating memory and then exiting? and even if that was the case, if I detach the memory from all processes that have it attached, and then delete it, it should be reclaimed by the system, not left hanging.

I'm detaching and deleting the segments from all processes that attach them at any point, and some of them are not getting freed after I tell the system to free them. in fact all of the ones that failed to delete are showing as being still attached after I tell the system to detach them.

this is certainly not an case where I am just allocating shared memory arbitrarily and then exiting and expecting the operating system to clean up after me. I am following the procedures recommended in the documentation, so I don't understand why some of the shared memory is remaining after I attempt to delete it.

if you really were trying to be helpful, it certainly didn't come across that way. I see that you have over 2900 posts, and I'd imagine that you're pretty well respected on this forum, but in my opinion, you really didn't contribute anything useful to the thread. in fact, your post seemed more condescending than anything. I'm not some n00b wanna-be hacker playing with my parents' computer. I have quite a few years of experience writing code for many platforms, including windows, linux/unix, and mac, so I have some idea what I'm doing.

if you have any helpful advice, I'd be glad to receive it, but your post really seemed like you were just trying to tell me that I don't understand the concepts of what shared memory is, or how the system handles it.

if I've misunderstood or mischaracterized your post, I apologize, but please offer constructive advice for how to solve my problem, rather than just telling me what you don't do, and reprimanding me for something that isn't even related to this thread.

Quote:

---

Originally Posted by Elkvis

did you read any of the previous posts in this thread?

---

Quote:

---

at what point did I say I was allocating memory and then exiting?

---

That's pretty much verbatim what you said.

Quote:

---

if I've misunderstood or mischaracterized your post, I apologize, but please offer constructive advice for how to solve my problem, rather than just telling me what you don't do, and reprimanding me for something that isn't even related to this thread.

---

I did offer constructive criticism, which you were too busy being indignant to notice. My suggestion is to not use SHM and use shared memory maps instead.

Are you calling shmget()/shmat() in the parent and child? Before or after fork()?

gg

Quote:

---

Originally Posted by brewbuck

That's pretty much verbatim what you said.

---

show me where I said that.

Quote:

---

Originally Posted by brewbuck

I did offer constructive criticism, which you were too busy being indignant to notice. My suggestion is to not use SHM and use shared memory maps instead.

---

without going into ANY detail about what you meant.

Quote:

---

Originally Posted by Codeplug

Are you calling shmget()/shmat() in the parent and child? Before or after fork()?

gg

---

in the parent I fork first, seeing as how it's pointless to allocate shared memory if no child process is created, and then create and attach the shared memory. once in the child process, I call shmget() and shmat(), using the same key (child PID + 0x10000000). I thought of one possible reason this could be happening. in the parent process, I have a thread running that monitors and acts upon the shared memory segments (one per child). when I free shared memory in the parent, I'm doing it from within this thread. is it possible that it's remaining attached in the main thread of the parent process, while being detached from the thread?

The kernel keeps its own copy of the shmid_ds strcuture associated with the shmid - so attachment counts are system-wide.

The reason I ask is because in SunOS/Solaris/AIX documentation, it explicitly states that children of fork() inherit existing attachments and the associated shm_nattach member of shmid_ds is incremented by 1 as a result of calling fork().

I don't know if this is the case on your system. If it were, then the following call order would be bad:
- parent-attach (++shm_nattach)
- fork (++shm_nattach)
- child-attach (++shm_nattach)

Since you say you're calling fork() fist, then this shouldn't be a problem.

gg

Quote:

---

Originally Posted by Elkvis

without going into ANY detail about what you meant.

---

I had assumed that since you were working with SHM, you must have already understood memory mapped files. Since that assumption was wrong, I'll explain.

Instead of a SHM segment with an identifier, you have a file in the filesystem. The identifier is the file path. Suppose you wanted to share a 10 megabyte segment between multiple processes. You create the segment by creating a file in the filesystem of size 10M. Call it /path/to/segment.

Then each process which wants to share that 10 megabyte space will open() the /path/to/segment file. Then, using the file descriptor returned, they would call mmap() to map that 10 megabyte space into their address space. At that point, the memory can be accessed just like a SHM segment. All the processes will see all changes to that memory.

The memory itself is cached on disk in the /path/to/segment file. This file will not be deleted by the operating system. So it "sticks around" like a SHM segment, but it sticks around on disk, not in memory, so it's nowhere near as much of a problem if nobody deletes it.

The performance of shared mmaps is identical to that of SHM segments.

You can read the man page for mmap() to figure out how to call it, and I'd be happy to answer questions about it.

Quote:

---

Originally Posted by brewbuck

I had assumed that since you were working with SHM, you must have already understood memory mapped files. Since that assumption was wrong, I'll explain.

---

I hope this little disagreement will have no lasting effect on our relationship. I'm fairly new to this board, and certainly don't want any bad blood with fellow posters. I'm willing to let this all be water under the bridge.

Quote:

---

Originally Posted by brewbuck

You can read the man page for mmap() to figure out how to call it, and I'd be happy to answer questions about it.

---

I'll look into it, but at this point, I'm not sure if it's really the ideal thing to use for my application, since I only allocate 32 bytes for each child process, and could potentially have hundreds of clients connected to the server. this could eat up disk space very quickly, considering that a file must allocate one whole block on the disk, and could have a lot of overhead, even if the block size was only 512 bytes.