[comp.sys.hp] too small mouse??

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