Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!purdue!decwrl!ucbvax!hplabs!hpfcdc!stroyan
From: stroyan@hpfcdc.HP.COM (Mike Stroyan)
Newsgroups: comp.sys.hp
Subject: Re: too small mouse??
Message-ID: <5570252@hpfcdc.HP.COM>
Date: 3 Aug 89 18:04:40 GMT
References: <1082@tukki.jyu.fi>
Organization: HP Ft. Collins, Co.
Lines: 51

> 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