🚀 go-pugleaf

Excerpts from internet.info-andrew: 25-Feb-90 Org Chart peculiarities J.
Mukerji@mtgzx.att.com (1597+0)

> I have noticed a few instances of strange behavior when using Org
> Charts. I was wondering if they are generic problems or am I doing
> something wrong.


It is (unfortunately) the case that a bug in any inset can be a time
bomb for a program like ez or messages.  Messages is particularly
vulnerable because when you go on to the next message, it actually
destroys the objects in the old message (ez tends to keep them around in
a buffer unless you use ^X^K, which is how you got your ez bug).  Often
the developer of an inset tests how it runs quite carefully, but doesn't
so carefully test how it dies,  which yields an inset that works fine
for demo purposes but causes particular problems when sent through the
mail.

I conjecture that one of three things is happening in the
xxx_FinalizeObject class procedure (where xxx is some one of the many
objects in the family of objects that make up the org inset and its apt
superclasses).  Either something is being freed that shouldn't be, or
something is being written past its allocated area, or an enqueued timer
event is not being cancelled.  I make this conjecture not based on the
code (because I don't know the org code, and don't particularly care to)
but based on considerably past experience with this type of bug report.

I suspect that this hypothesis explains your bugs #1 and #3.  As to #2
-- where an org inset in the sendmessage window caused the X server to
dump core -- this is obviously harder to diagnose.  Clearly there is a
bug in the X server, but (if this is reproducible) undoubtedly some
ATK/org bug triggers it.  Conceivably the symptom will go away when the
other bug is fixed, but i wouldn't count on it.  -- Nathaniel