[Date Prev][Date Next][Subject Prev][Subject Next][ Date Index][ Subject Index]

Re: Stack; Abnormal termination of MeNu frames; the Escape key



** Reply to message from "M.C."  on Fri, 09 Jan 2004 20:20:00
+0100

Manuel:

> "Stability problems" were crashes of the program,
> something very unusual in my former experience under W2K.

OK. Thanks for pointing this out. I never use the menus, so haven't
encountered this for a long time. But, yes, you are absolutely correct:
instability (specifically, out of memory) can occur if a Stacking key is hit
during MeNu entry. As Stack is presently constituted (but fix discussed
below), users need to be careful about Enter versus the alternate Enter
(Grey-Enter, Shift-Enter, whatever you have devised).

The cause of the instability, in brief, is what's called a "malloc" error,
memory allocation -- a genuine "memory leak" (the term seems a bit grandiose in
the context of XPL, but it can bring XyWrite down finally like any memory
leak). Caused, in this case, by the abnormal termination of a MeNu frame.
"Abnormal" termination of a MeNu frame has the effect of committing to
permanent memory a portion of the MeNu code (every byte that you've accessed
before you hit the wrong Enter key). This could have been avoided by the
designer (Erickson), but I guess he never focused on it, or it was an
unintended consequence. This memory cannot be de-allocated -- you can't get
rid of it (AFAIK), it just starts filling up the XPL memory buffer. So if you
hit the wrong Enter key too many times while in the midst of MeNu operations,
causing an abort, eventually you can run Out Of Memory (OOM). How many times?
I would say more than four or five and you're treading on thin ice. OOM is
synonymous with doom -- you're kaput when OOM happens. Gotta Quit and relaunch.

The best tool to show what is going on is frame LISTSAVS. It displays
precise info re: Save/Get memory, including the "special" Save/Gets that
contain these abnormal termination phenomena. It is hard to overstate the
importance of LISTSAVS for memory analysis. SGDIAG and MACRODIAG ?D
are barebones reports about the same situation.

Because you cannot (to my knowledge) get rid of (write to, or otherwise
manipulate) this "special" memory, the only viable strategy is to trap and
inhibit abnormal termination before it commits memory -- to put a safety lock
on the trigger. Not too difficult. We're concerned here primarily with three
keys: F9 (or whatever your normal eXeCute key is), Stacking Enter, and Escape.
The first two can be handled entirely within Stack's code. I've uploaded a new
STACK.DLG block of frames, to be inserted in your DLG file, here:

 http://holmgren.home.acedsl.com/stackxyw.zip

and you can install it now (I'm going to watch this closely in coming days, and
I may modify the code again). Obviously, this invalidates yesterday's
statement that a ready-to-go version of Stack was at xywrite.com -- the code at
the URL above is the code to use, and anyway, you need the DOC file to learn
how to use Stack, which is NOT (to my knowledge) available at xywrite.com.

The Escape key is also treated as abnormal termination by MeNu frames -- this
is entirely unrelated to Stack, but it also needs a fix. To protect the Escape
key, you need two things:
 - two new frames inserted in U2 (or DLG)
 - a new KBD file assignment for the Escape key, which is key #1
  in every KBD Table

Note that the effect of ALL these fixes is to _cancel_ your MeNu selection
_and_ your intended keystroke. You will have to start over, and hit the
correct key(s) this time.

For users who use Stack, but not U2
=== ===== === === ===== === === ==
The Escape key fix, and the Stack fixes, are very similar but not identical.
In each case, the "fix" consists of two new frames that need to be added to a
Help file -- four frames altogether. My design is that two of them be part of
the Stack code and therefore go in DLG, while the Escape key fixes go in U2.
But you can put all four in DLG if you don't have a U2 file (see key specific
assignments below).

Note well that these fixes do not affect some DiaLoG [DLG] frames, launched
originally from MeNu frames, but generally buried down deep in the hierarchical
structure of Help. In these cases, the Escape key just does nothing,
harmlessly. These dialogs can only be dismissed by tabbing over to the
"Cancel" pushbutton, or by hitting a key with just unadorned func ES (or the
Ascii-27 character) on it, or the accelerator key+"C". One solution is to put
a _real_ Escape (func ES or Ascii-27) on a secondary Escape key, like
RightShift-Escape. If you have the habit of using accelerator keys, you won't
get in any trouble.

Because I plan to stop participating (permanently) in this maillist soon, I
want to cover some essential questions before I quit. I'm going to establish a
separate OOM page at XyWWWeb, where the full range of OOM problems can be
discussed. Here are two examples, describing issues that are largely unknown.

1) Each time you load (or reload, or LOADHELP) the DLG file, an
additional copy of the descriptive keyboard table (DLG frame "1B") is committed
irretrievably to memory. As presently constituted, that's about 870 bytes per
copy. If you alter and reload DLG too many times, you WILL run out of memory.
Therefore, after making changes to DLG, it is wise to Quit and relaunch XyWrite.

2) Certain of the "special" Save/Gets _can_ be removed from memory, or zeroed
out. E.g. the S/Gs beginning at *26dec [*001Ahex]. I will post a routine
which accomplishes that; it MUST be RUN, as a freestanding program. Other
special S/Gs, however, especially those beginning at (and incrementing from)
*13843 [*3613h] are (AFAIK) untouchable. If anyone (Chris?) knows how to write
to the special S/Gs (the ones displayed in DLG frame MACRODIAG), I'd be obliged
if they would describe the method. There may well be some "secret".

Fixes
=====
Stack fixes are at the URL mentioned above

Escape key fixes:
Change the Escape key as follows:
 from
1=ES (or variants thereof)
 to
1=NOJM2,.,n,u,l,l,Q2 <==assignment if you use U2
 or
1=NOJMn,u,l,l,Q2   <==assignment if you do NOT use U2

Add these frames to U2 (they will be part of U2 v116, forthcoming in a few
days, so you could wait for that before making any changes) or to DLG:

XPLeNCODE v2.0
b-gin [UNTITLED]
{{;5null}} Null Frame (null special S/Gs *26,*27,*29) RJH La
stRev.1/10/04[cr|lf]{002}{<}SX51,{<}VA$TX{>}{>}{<}IF{<}VA$SM{
>}>0{>}[B4_]{<}EI{>}[ES_]{<}IF{<}VA$SM{>}>0{>}[JM_]2.Cancel[Q
2_][cr|lf]{<}EI{>}{<}IF{<}PV51{>}<1{>}[GH_]{<}EI{>}{002}[cr|l
f][cr|lf]{{KCancel}} Cancel MeNu Frame (VA$SM=1) without comm
itting memory RJH 1/10/04[cr|lf]1{tab}1{tab}8{tab}8{tab}14{t
ab}3{tab}[cr|lf]dp*{tab}2{tab}2{tab}1{tab}10{tab}1{tab}&Cance
l[cr|lf]{002}{002}{002}[cr|lf][cr|lf]
-nd
XPLeNCODE