[Oberon] System Freeze on module unloading

Wed Aug 21 13:26:44 CEST 2002

I believe the best way to solve the problem is to have a termination handler
for each module.
Which should be called by the system whenever a module is unloaded. This
handler can then free
the required memory and patch up any dangling references. If memory serves
there is already
such a mechanism in place - don't ask me for the details though I haven't
had a look at the code
in ages and besides I still use 2.3.6...

Anyway if it is no longer there such a mechanism is easy to implement.

The problem is of course that this is such a schlep to implement in each
module after the fact. It is of course
trivial to implement if incorporated during module development.

  Frank
---------------------------------------
Frank van Riet (Software Developer)
Datavoice  (Pty) Ltd 
Snail mail	PO Box 582
		Stellenbosch 7599 
		South Africa 

Tel         +27 21 888-2118
Mobile	+27 82 970 5704

Web 	      http://www.datavoice.co.za
----------------------------------------

> -----Original Message-----
> From: oberon-request at inf.ethz.ch [mailto:oberon-request at inf.ethz.ch]
> Sent: 21 August 2002 12:00
> To: oberon at inf.ethz.ch
> Subject: Oberon digest, Vol 1 #51 - 3 msgs
> 
> 
> Send Oberon mailing list submissions to
> 	oberon at inf.ethz.ch
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://www.lists.inf.ethz.ch/mailman/listinfo/oberon
> or, via email, send a message with subject or body 'help' to
> 	oberon-request at inf.ethz.ch
> 
> You can reach the person managing the list at
> 	oberon-admin at inf.ethz.ch
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Oberon digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Project Oberon Source Code (Pat Hacker)
>    2. Re: ETH Oberon/Gadgets: System Freeze in unloading 
> (Patrick, Dr. med. Hunziker)
>    3. Re: ETH Oberon/Gadgets: System Freeze in unloading 
> (Felix Friedrich)
> 
> --__--__--
> 
> Message: 1
> From: "Pat Hacker" <pat at picoworks.com>
> To: <oberon at inf.ethz.ch>
> Subject: Re: [Oberon] Project Oberon Source Code
> Date: Tue, 20 Aug 2002 07:04:28 -0700
> Reply-To: oberon at inf.ethz.ch
> 
> Felix,
> Thanks for the pointers.  As you mention there seems to be 
> minor differences
> in the core modules between the source in the Project Oberon 
> book and V4 so
> I'm using V4 source for now.
> Pat
> 
> 
> 
> --__--__--
> 
> Message: 2
> Date: Tue, 20 Aug 2002 13:40:07 +0200
> From: "Patrick, Dr. med. Hunziker" <PHunziker at uhbs.ch>
> To: <oberon at inf.ethz.ch>
> Subject: Re: [Oberon] ETH Oberon/Gadgets: System Freeze in unloading
> Reply-To: oberon at inf.ethz.ch
> 
> >>Gadgets.Insert BasicGadgets.NewButton
> >>to Insert a button somewhere.
> >>Then I execute
> >>System.Free BasicGadgets~
> >> makes the system freeze...
> 
> >Felix wrote: 
> >Don't be so cruel to the poor Button. You have stolen its 
> Handler. ;-) 
> >Seriously: The Problem is: When freeing a Module, Oberon 
> checks if there 
> >are still other Modules depending on that module but it 
> cannot check if 
> >Objects are still using any Allocated Memory in that Module. In that 
> >special case the allocated Memory was the Handler and moreover any 
> >type-checks and type-casts could't work since the Module did 
> not exist any 
> >more (after successful freeing it) etc.
> 
> >So the "solution" is: Do not System.Free a Module when its 
> Objects are 
> >still displayed, since they are not deallocated and the 
> Handler is called 
> >any time a Display.Broadcast (or update message) is sent 
> (which is the case 
> >when new Viewers like a Trap-View are opened.)
> 
> >Felix.
> 
> Thanks for the info.
> I see the problem.
> However, in several years of working with Oberon, I have only 
> found three ways to produce C-like system freezes
> apart from using the unsafe SYSTEM feature:
> A) calling C programs from within Oberon
> B) passing very large arrays as value parameters in procedure headings
> C) unloading modules whereby some visual gadget is still 
> hanging around somewhere, as mentioned above.  
> I feel system stability is a prominent one of the many 
> highlights of Oberon, so the points B and C hurt the more...
> Greetings
> Patrick
> 
> 
> --__--__--
> 
> Message: 3
> Date: Wed, 21 Aug 2002 10:58:44 +0200
> To: oberon at inf.ethz.ch
> From: Felix Friedrich <friedrich at gsf.de>
> Subject: Re: [Oberon] ETH Oberon/Gadgets: System Freeze in unloading
> Reply-To: oberon at inf.ethz.ch
> 
> Hi Patrick
> 
> >However, in several years of working with Oberon, I have 
> only found three 
> >ways to produce C-like system freezes
> >apart from using the unsafe SYSTEM feature:
> >A) calling C programs from within Oberon
> >B) passing very large arrays as value parameters in 
> procedure headings
> >C) unloading modules whereby some visual gadget is still 
> hanging around 
> >somewhere, as mentioned above.
> >I feel system stability is a prominent one of the many highlights of 
> >Oberon, so the points B and C hurt the more...
> 
> I agree. By the way problem B) occurs because the max stacksize of an 
> Oberon.Thread (in Windows) is approx. like 100kB. I have 
> increased that 
> value to 1MB in my threads, but anyway, the best "solution" 
> is to take 
> VAR-pars or Pointers. As far as I know, in Windows-Oberon it is a 
> Windows-Problem, since the Windows-thread crashes when the 
> size of the 
> stack is too small. Maybe there should be some built in 
> range-check for the 
> stack in Oberon. (possible?)
> Do you see a solution for C) ?
> 
> Felix.
> --
> 
> Felix Friedrich
> 
> Institut für Biomathematik und Biometrie
> GSF - Forschungszentrum für Umwelt und Gesundheit, GmbH
> Ingolstädter Landstraße 1, D-85764 Neuherberg
> 
> Tel:      ++49 89 3187 2436
> email:  friedrich at gsf.de
> 
> --
> 
> 
> 
> --__--__--
> 
> --
> Oberon at inf.ethz.ch mailing list for ETH Oberon and related systems
> http://www.lists.inf.ethz.ch/mailman/listinfo/oberon
> 
> 
> End of Oberon Digest
> 