Mouse handler table inconsistency.

[Spock@SAMSON.cadr.dialnet.symbolics.com (Mr. Spock)]

    Date: Thu, 5 Apr 90 09:38 PDT
    From: RDP@ALAN.kahuna.decnet.lasc-research.lockheed.com (Robert D.
	  Pfeiffer)

    [SLUG added in case anyone else out there has been experiencing the
    following symptom and has any insight.  We're currently running 8.0 Beta
    but I have no reason to believe that this problem is specific to that
    version of Genera.]

	Date: Wed, 4 Apr 90 17:53 PDT
	From: Mark Freeman <MFreeman@VERMITHRAX.SCH.Symbolics.COM>

	    Date: Mon, 2 Apr 90 14:58 PDT
	    From: Robert D. Pfeiffer <RDP@ALAN.kahuna.decnet.lasc-research.lockheed.com>

	    "Once in a while", our application generates the following notification.
	    I have no idea why.  As it says, the problem is automatically corrected
	    so it's no big deal.  Nevertheless, it bothers me that there's something
	    wrong which I don't understand.  Can anyone provide some insight as to
	    what this might mean and how to fix it properly? 

	    3/21 10:48:46 An inconsistency was found in the mouse handler tables
			  OPTIM::SELECT-THIS-OBJECT is missing from the table
			  at context = CP:COMMAND
			  and displayed = OPTIM::PSEUDO-TASK
			  Entry = (OPTIM::SELECT-THIS-OBJECT
	    -PREDICATE-INTERNAL 0 TYPE...
			  Entry-list = NIL.
			  It will be automatically corrected.

	I think the problem is that Entry-list is NIL.  The Entry-list
	is obtained from the table
	dw::*presentation-type-mouse-handler-table*, so for some reason,
	dw::verify-handler-entry-in-table can't find the handler table
	element for handler OPTIM::SELECT-THIS-OBJECT.  As the message
	says, it will go ahead and create the entry-list for you.  I'm
	not sure why that could be missing, maybe the table didn't get
	copied correctly while it was being grown, or mutated?  

    I'm sure I don't know.

I bet there is a problem with the table.  I have a similar type of
lossage happening in the character-style mapping table.  I have an
initialization that causes the file-server>init.lisp file to be read at
boot time.  This file has sys:enable-services in it.  Every once in a
while when booting the machine it will go into the debugger before
getting to the initial lisp-listener.  The error is something like "No
mapping for swiss.roman.normal ...".  The name of the style sometimes
differs but it's always a style that *should* be defined.  It usually
happens when trying to set up the domain-name server log.  It was hard
to trace but as far as I could tell the table that is used for mapping
character-styles to fonts was mutating and didn't get locked correctly
so I wouldn't be surprised if there's a subtle bug in the mutating code.
We all know how hard it is to mutate.  (I fixed this by forcing the
lookup to be repeated if it returns NIL the first time.  And, yes I
reported this.)  I've seen this in 7.2 and 7.2.2 and I think 7.1.
--Mark Alexander

							       Does it
	always happen on one of your own defined handlers?

    Yes, so far as I know.

	P.S. Setting *background-notifies-for-missing-handlers* to NIL
	should make the notifications go away.  (but
	dw::verify-handler-entry-in-table will still fix things for you)

    Thanks, I'll use this as a last resort if I can't fix my application
    properly before it goes into Beta Test.