Problems with shared memory shmdt() shmctl()

This is a discussion on Problems with shared memory shmdt() shmctl() within the C Programming forums, part of the General Programming Boards category; Hi, I have a simple application under way that is invoked multiple times with different command line arguments. Each invocation ...

  1. #1
    Registered User
    Join Date
    Mar 2009
    Posts
    1

    Problems with shared memory shmdt() shmctl()

    Hi,

    I have a simple application under way that is invoked multiple times with different command line arguments. Each invocation accesses a common piece of shared memory for a different task. Display to monitor or file; Mysql interface; query data from machines and post to a structure in shared memory; (beginning to really like those semicolons) watch for specific abberant machine behaviour and send a corrective command. One arguement posts a flag that tells them all to die.

    This all works

    It works well enough that even if all the delays and watch-outs are inhibited in the code, half a dozen processes reading and writing to the same memory have run flat out for 48 hours without logged conflicts or memory leakage

    The problem is that after any process times out and quits or is instructed to shut down by a command from a terminal, no further processes are able to attach to the memory. The next invocation creates and attaches another region of shared memory Subsequent invocations attach to second set of processes instead of the first, which still may still be active.

    IPCS and top show predictable data. The number of attached processes increments and decremnts as it should. The creation of a new set of processes using a new piece of shared memory show up as expected.

    One header of one column of the ipcs display looks as if should list some version of KEY but that part of the display is all 0s in my version. Anyone know about this?

    There is something I do not know about accessing and releasing shared memory. The procedure is right out of the book:

    Code:
          int shmid = shmget((key_t)mykey, bulk(),0666 |IPC_CREAT);
     
       if (shmid == -1) {
          fprintf(stderr, "shmget failed\n");
          goto shut_down_relay;
        	}
    
        shared_memory = shmat(shmid, (void *)0, 0);
    
        if (shared_memory == (void *)-1) {
            fprintf(stderr, "shmat failed\n");
            exit(EXIT_FAILURE);
        }
    
        printf("\nMemory attached at %X  shmid = %d\n", (int)shared_memory, shmid);
        
        .
        .
        .
        .
    				
       if (shmdt(shared_memory) == -1) 
    
            fprintf(stderr, "shmdt failed\n");
      		else printf("detached memory");			
    			printf( "shmid %d", shmid);
    
        
        if (shmctl(shmid, IPC_RMID, 0) == -1) 
    
            fprintf(stderr, "shmctl(IPC_RMID) failed\n");
    		else printf(" released memory ");
    The values of shared_memory and schmid are not modified anywhere in the code. Test print statments show that they are the same at exit as at acquisition.

    The execution and development platform is a modest Ubuntu Linux machine with plenty of memory and processing capacity. The processes are now run from multiple Gnome terminal windows.

    All routines exit through the same piece of code. There is only one exit() in the entire program. It compiles cleanly with -Wall


    RATS! I just solved this well documented stupid repeateable problem, but the solution is informative so it gets posted.

    After reading the pages for shmctl() a dozen times I realized it destroys the memory segment on every call, not a matter of "last one out turns off the lights". Got rid of it in the shut down code, just shmdt() now, and every thing is perfect. In this application it is a non_issue to leave 11206 bytes of memory stranded. The only things the computer does is perform these contol and logging functions. If the memory stays allocated to KEY and it is always the same KEY, the memory will still be there when the processes come back, and, as kind of an undependable bonus, will be filled with generic process data that may not cause any drastic process jerks before new data accumulates.

    The clue was that as I was testing this question for repeatability, I realized that processes that exited with a ^c did not cause the problem.

    Is a day wasted on education really wasted? I learn, but there is blood on the walls and ceiling.

    I hope this helps someone avoid a problem.

    J Carroll

  2. #2
    Resu Deretsiger Nightowl's Avatar
    Join Date
    Nov 2008
    Location
    /dev/null
    Posts
    186
    Is a day wasted on education really wasted?
    Never. Never, ever, ever.

    Also, thanks for the heads-up. Will keep this in mind next time I'm working with shared memory.
    Do as I say, not as I do . . .

    Experimentation is the essence of programming. Just remember to make a backup first.

    "I'm a firm believer that <SomeGod> gave us two ears and one mouth for a reason - we are supposed to listen, twice as much as we talk." - LEAF

    Questions posted by these guidelines are more likely to be answered.

    Debian GNU/Linux user, with the awesome window manager, the git version control system, and the cmake buildsystem generator.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Mutex and Shared Memory Segment Questions.
    By MadDog in forum Linux Programming
    Replies: 14
    Last Post: 06-20-2010, 05:04 AM
  2. BSD mmap for shared memory - am I right?
    By sean in forum Linux Programming
    Replies: 21
    Last Post: 03-09-2009, 02:57 PM
  3. Replies: 7
    Last Post: 02-06-2009, 12:27 PM
  4. Question regarding Memory Leak
    By clegs in forum C++ Programming
    Replies: 29
    Last Post: 12-07-2007, 01:57 AM
  5. Memory Allocation/Freeing Problems
    By Unregistered in forum C Programming
    Replies: 6
    Last Post: 05-29-2002, 09:50 AM

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