tarvaine@tukki.jyu.fi (Tapani Tarvainen) (08/02/89)
How is it possible to run out of space *on a mouse*: Starbase error 2053: Shared memory call failed. procedure name: track File descriptor: 7 Device file name: /dev/locator Library location: operating system utilities (0) System errno: No space left on device. We have a 9000/370 server and diskless 319s and 340s, running HP-UX 6.5. The error is rather weird: After boot everything works fine for several days, but then it seems the mouse fills up and won't work until reboot. What does this mean? The same phenomenon occurs with all locally written programs that use Starbase or GKS; it is possible that something is wrong in the programs, any ideas where to look? It is also possible that the programs are occasionally terminated violently, perhaps something they've reserved isn't freed then. (In any event I think whatever resources are allocated to them should be released when the programs terminate.) Is there any way to clear the mouse, short of booting? -- Tapani Tarvainen (tarvaine@jyu.fi, tarvainen@finjyu.bitnet)
blaho@hpfcdq.HP.COM (Bruce Blaho) (08/03/89)
>How is it possible to run out of space *on a mouse*: > >Starbase error 2053: Shared memory call failed. > procedure name: track > File descriptor: 7 > Device file name: /dev/locator > Library location: operating system utilities (0) > System errno: No space left on device. > >We have a 9000/370 server and diskless 319s and 340s, running HP-UX 6.5. >The error is rather weird: After boot everything works fine for >several days, but then it seems the mouse fills up and won't work >until reboot. > >What does this mean? It means that you are running out of shared memory segments (the device referred to in the errror message is not the mouse, but the computer) probably due to previous violent terminations of your application. Rebooting cleans up all the shared memory segments and gives you a clean slate. There is a much easier way to fix this. Use the 'ipcs' command to see system wide shared memory segments (as well as semaphores and message queues.) You will probably see a long list of segments owned by whoever was running your application. Assuming you are not running your application (or a window system) most if not all of these can be blown away. Use 'ipcrm -mID' to remove unused shared memory segments, where 'ID' is the shared memory segment ID found with 'ipcs'. There may be a lot of leftover semaphores too, which can be removed with 'ipcrm -sID.' Be careful not to remove shared memory or semaphores owned by 'root' or in group 'sys'. When you initiate cursor tracking, a shared memory segment is allocated to allow communications between a tracking daemon process and your parent process. Shared memory segments are allocated by the OS on a system wide basis and must be explicitly removed (e.g. they don't automatically go away when your process terminates.) Normally the graphics system would remove the segment when you close Starbase or GKS. But if your process is violently terminated (as you mention below) we may not have a chance to clean up. There is a fixed (configurable) number of shared memory segments for a given system. Once the limit is exceeded, subsequent OS calls fail (like above.) >The same phenomenon occurs with all locally written programs that use >Starbase or GKS; it is possible that something is wrong in the >programs, any ideas where to look? It is also possible that the >programs are occasionally terminated violently, perhaps something >they've reserved isn't freed then. (In any event I think whatever >resources are allocated to them should be released when the programs >terminate.) > >Is there any way to clear the mouse, short of booting? > As I mentioned above, the problem is that system wide resources can't be automatically released when one process terminates, since other processes might still need them. You need to actually close down the graphics system to let us release these. GKS uses the same OS utilities as Starbase, so the problem is the same for both. To fix your problem you can either 1) periodically remove left over shared memory segments and semaphores using 'ipcrm', or 2) modify your application to always do a proper 'gclose' before terminating (e.g. catch signals resulting from the break key or whatever is causing your application to terminate violently.) >-- >Tapani Tarvainen (tarvaine@jyu.fi, tarvainen@finjyu.bitnet) Bruce Blaho HP Graphics Technology Division
stroyan@hpfcdc.HP.COM (Mike Stroyan) (08/04/89)
> How is it possible to run out of space *on a mouse*: > > Starbase error 2053: Shared memory call failed. > procedure name: track > File descriptor: 7 > Device file name: /dev/locator > Library location: operating system utilities (0) > System errno: No space left on device. > > We have a 9000/370 server and diskless 319s and 340s, running HP-UX 6.5. > The error is rather weird: After boot everything works fine for > several days, but then it seems the mouse fills up and won't work > until reboot. > > What does this mean? The message is trying to say that the library can't allocate a shared memory segment. The shared memory is used to communicate between the application process and a second process that does the asynchronous echo updates for tracking. The 'No space left on device' message is the generic message for the ENOSPC errno value that a 'shmget' kernel call returned. It means that the system limit of shared memory identifiers has been exceeded. Previous programs that were violently terminated have left behind their shared memory segments, using up the available shared memory ids. The System V shared memory definition allows a shared memory segment to exist when no process is using it. This can be good, since there may be data in the shared memory that a later program will use. Unfortunately, System V does not allow a group of processes to make a shared memory segment that can be used by new processes, but is destroyed when the last accessing process exits. The Starbase library removes its shared memory segements when the program calls gclose. It also cleans up if tracking or events are in use and the daemon process notes that the application process has exited. The shared memory will not be removed if you kill a Starbase application that has done tracking or event queueing and is not doing either when you kill it. > Is there any way to clear the mouse, short of booting? You can free the shared memory segments by finding their id numbers with 'ipcs -mo' and removing them with 'ipcrm -m <id>'. It is sometimes difficult to tell if a shared memory segment is left over or in use. If 'ipcs -mo' shows a segment with a 'KEY' of '0x00000000' and 'NATTCH' of '0', it is a 'private' segment with no process attaching it. This is what left over Starbase shared memory segments will look like. They will be owned by the user that ran the program. > Tapani Tarvainen (tarvaine@jyu.fi, tarvainen@finjyu.bitnet) Mike Stroyan, stroyan@hpfcla.hp.com