shared memory not getting freed

This is a discussion on shared memory not getting freed within the Linux Programming forums, part of the Platform Specific Boards category; Originally Posted by brewbuck That's pretty much verbatim what you said. show me where I said that. Originally Posted by ...

  1. #16
    Registered User
    Join Date
    Oct 2006
    Posts
    2,590
    Quote Originally Posted by brewbuck View Post
    That's pretty much verbatim what you said.
    show me where I said that.

    Quote Originally Posted by brewbuck View Post
    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.

  2. #17
    Registered User
    Join Date
    Oct 2006
    Posts
    2,590
    Quote Originally Posted by Codeplug View Post
    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?

  3. #18
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,702
    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

  4. #19
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,274
    Quote Originally Posted by Elkvis View Post
    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.

  5. #20
    Registered User
    Join Date
    Oct 2006
    Posts
    2,590
    Quote Originally Posted by brewbuck View Post
    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 View Post
    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.

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Assignment Operator, Memory and Scope
    By SevenThunders in forum C++ Programming
    Replies: 47
    Last Post: 03-31-2008, 07:22 AM
  2. Shared Memory...
    By suzan in forum Linux Programming
    Replies: 1
    Last Post: 02-16-2006, 02:29 AM
  3. shared memory can not read value over 255
    By jbsloan in forum C Programming
    Replies: 4
    Last Post: 04-03-2005, 12:56 PM
  4. pointers
    By InvariantLoop in forum C Programming
    Replies: 13
    Last Post: 02-04-2005, 09:32 AM
  5. Shared memory in Linux: B-TREE of structures
    By zahid in forum Linux Programming
    Replies: 3
    Last Post: 01-26-2002, 11:15 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21