[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Mouse handler table inconsistency.
Date: Thu, 5 Apr 90 09:38 PDT
From: RDP@ALAN.kahuna.decnet.lasc-research.lockheed.com (Robert D.
[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.
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.