Unsafe module unloading

[DGDanforth]

The following discussion was taken from the Oberon mailing list.
It points up a hidden weakness in unloading modules. The code below was written
for (I think Oberon-7) but the same code (with EXTENSIBLE added) also fails (traps)
for Component Pascal.
One would not expect the sequence Load, Unload, Load to trap.
-Doug
===
Andreas

I imagine the following, admittedly artificial, setup:

MODULE A contains a list L of some R0 = POINTER TO RECORD ... END
For example A provides base type and repositories of geometric figures.

MODULE B imports A and declares R1 = POINTER TO RECORD (A.R0) .. END;
For example R1 describes a circle.

MODULE C traverses the list of A identifying every B.R1 element with a type test:
IF element IS R1 THEN (* e.g. remove it from the list A.L *) END;
For example C constitutes a graphics program providing a mechanism to remove all circles from a plot.

The problem is that if B is unloaded after some circles had been deposited in A.L and if B is loaded again and only then C is becoming active, it will only remove elements from the new B but not of the older B: there will still be circles in the plot.


Minimal Test code:

MODULE A;
TYPE R* = POINTER TO RECORD END; (*For Component Pascal make that EXTENSIBLE RECORD*)
VAR r*: R;
END A.

MODULE B;
IMPORT A;
TYPE R* = POINTER TO RECORD(A.R) END;
VAR r: R;
BEGIN
NEW(r);
IF A.r = NIL THEN
A.r := r;
END;
END B.

MODULE C;
IMPORT A,B;
BEGIN
IF A.r IS B.R THEN A.r := NIL END; (* problem: type test refers to "new" version of B.R while an instance of an old version of B.R is still existing. *)
ASSERT(A.r = NIL);
END C.

Load Module C.
System.Free C ~
Load Module C. (--> TRAP)

Rgds
Felix

[Josef Templ]

Firstly, I think the folks in the oberon mailing list are mixing up the occurrence
of a trap (no problem) with the occurrence of a system crash (a problem indeed).
A system crash can result from
(1) using undefined code after module unloading due to reusing the module's code
memory for something else, or
(2) from recursive traps, where the trap handler produces another trap
that produces another trap etc.

Secondly, based on years of experience with the original ETH Oberon system
these problems were well known to the ominc people and BlackBox
solves them cleanly.

In BlackBox (1) cannot happen because the module's code memory is never reused.
Also (2) is cared for in BlackBox for the most important situations: Views and Actions.
A trap in the handler of a view would lead to a recursive trap because the
standard trap handler broadcasts messages to all views. Unloading the module
that implements a view would produce a trap when calling the view's handler.
However, in BlackBox such views are deactivated automatically and produce a greyed
representation of the view. This is not only done for traps resulting from unloaded
handlers but for all traps that are produced from a view because any trap in a view
has some potential for producing a recursive trap.
Actions can decide themselves if they are to be reactivated after a trap or not.
This is expressed by calling DoLater either at the beginning or at the end of the
action's Do method.
In addition there is the CLOSE section in a module that can be used for
some cleanup work upon module unloading.

- Josef

[luowy]

Andreas's safe unloading module is very interesting,I think.we'd better port it to our framework.

[Josef Templ]

I have added a wiki page on that subject,
see http://wiki.blackboxframework.org/index ... eUnloading.
It explains why BlackBox is far ahead of the experiments in the oberon mailing list.

@Ivan: when I was finished I tried to rename the title but could not find any button for that.
Is "page move" deactivated? The docu says it is possible to rename a page.

- Josef

[Ivan Denisov]

@Ivan: when I was finished I tried to rename the title but could not find any button for that.
Is "page move" deactivated? The docu says it is possible to rename a page.

We are using default settings for editing. The easiest way I know is to make new page with desired title and copy content there. Then remove all the content from old page.

[luowy]

BB Kernel.Unload only decommit the mem region of the unloading module, not released for protection,
it is better than ETH oberon one.

I have private project,make a JIT for a small script language run in the framework,e.g regular expression script for search,repalce ... that need to load and unload the temp module which emmitted by JIT many times,the temp moudle run once and thrown away, no need reserved it's old mem at all. but release it's mem without throughly checking the unloading module's objects it's unsafe like old ETH Oberon OS!

for safely unloading the BB module, and clear it throughly, I want port Andreas's solution to BB framework;
any suggestion is welcome.

[Josef Templ]

Since safe module unloading is already implemented in BlackBox there is absolutely no need
to make any changes. We can safely ignore this issue.

Safe module unloading as implemented in the experimental oberon
mentioned in the oberon mailing list makes only sense in the context of
that oberon implementation, which may crash the system
when calling procedures of unloaded modules.
Sorry if I repeat myself but there is a big difference between a trap
and a system crash.

- Josef

[Robert]

Since safe module unloading is already implemented in BlackBox there is absolutely no need
to make any changes. We can safely ignore this issue.

I have been getting some TRAPs in my code, which I don't properly understand, but I think may be related to this issue.

Would it be possible / simple / desirable to change the TRAP headline message from "illegal execution" to "attempt to use unloaded module"?

I think that is what I am doing, but a more specific diagnostic message would be helpful.

[Josef Templ]

I think that is possible at least as an additional hint.
Also "ad = ..." should probably be changed to "adr = ..." if that is what it shows.

If the text is changed then we must be 100% sure that it is really an attempt to access an unloaded module.
Otherwise it would be misleading in some situations. If we are not 100% sure, and I am not 100% sure,
it should be added as an additional text, e.g.

illegal execution (adr = ...; call of unloaded code?)

or some similar formulation.

- Josef

[Robert]

"ad =" occurs many times in the code, so changing it to "adr =" is probably not worth the effort.

I think we are talking about error # 205, which is recognised in Kernel.TrapHandler. I guess that to confirm that the error is due to module unloading it is necessary scan the list of unloaded modules (if such a list exists ?).

Again; probably not worth the effort.