FilterWindow has already been instantiated for this session.

The problem is most likely due to a residual shared memory segment. When some CIAO applications exit ungracefully, e.g. by CTRL-c, they do not get a chance to free up the shared memory segment to which they were attached. This segment stores information regarding the applications running in a session.

The session code is being updated to deal with abnormal terminations and proper cleanup. In the meantime, the shared memory segments can be cleared up as follows:

1. Use the utility ciaoshmem to check for remaining shared memory. When run without options, it gives a shared memory id as well as information regarding applications it thinks are still part of the session:

   unix% ciaoshmem
   
             The current session for this window...
    -------------------------------------------------------- 
    |  session id: v2.0.egalle.lobo.                       |
    |  shm id:                 16200                       |
    |  - - - - - - - - - - - - - - - - - - - - - - - - -   | 
    |  Application   Instance   Process id   Access Name   |
    |  -----------   --------   ----------   -----------   |
    |  filtwin           1         14111     filtwin       |
    |  prism             1         14112     prism         |
    -------------------------------------------------------- 
   

   Note that the shared memory identification (shm id) is 16200 in this example.

2. The Unix ipcs command will return shared memory and semaphore info (but not how they relate to CIAO):

   unix% ipcs
   IPC status from <running system> as of Wed Jul  9 14:56:57 EDT 2003
   T         ID      KEY        MODE        OWNER    GROUP
   Message Queues:
   Shared Memory:
   m      16200   0xf98bea   --rw-rw-rw-   egalle     head
   Semaphores:
   s    4718592   0xf98bea   --ra-ra-ra-   egalle     head
   

   The entry with the shared memory id that matches that from the ciaoshmem call (16200) indicates that the shared memory segment still exists. In addition, the semaphore (used as a shared memory lock mechanism) also remains. This is recognized by matching the key 0xf98bea from the shared memory segment with that of the semaphore.

3. Running ciaoshmem with the -c option generally will remove any CIAO session shared memory and semaphore info for a given session id. Since it will remove the shared memory and semaphore even if the user is logged into the same host machine using the same display, it should not be used if any applications are still running.

   unix% ciaoshmem -c
   

4. Performing another ipcs or ciaoshmem command should indicate that the memory has been removed:

   unix% ipcs
   IPC status from <running system> as of Wed Jul  9 15:00:36 EDT 2003
   T         ID      KEY        MODE        OWNER    GROUP
   Message Queues:
   Shared Memory:
   Semaphores:
   
   unix% ciaoshmem
   
             The current session for this window...
    -------------------------------------------------------- 
    |  session id: v2.0.egalle.lobo.                       |
    |  shm id:                 16400                       |
    |  - - - - - - - - - - - - - - - - - - - - - - - - -   | 
    |  No applications are attached to this session.       |
    -------------------------------------------------------- 
   

   The session memory id has changed since the old session has been removed.

5. If the ciaoshmem -c call fails to work, the user can manually remove the shared memory segment and semaphore using the Unix ipcrm command. Please read man ipcrm before using this command since the syntax varies slightly across operating systems. For the example above, the command would be:

   unix% ipcrm -m 16200 -s 4718592
   

   The -m option removes the shared memory specified by id 16200 and the -s option removes the semaphore specified by id 4718592.