[Oberon] Re. Bluebottle low on heap

easlab at absamail.co.za easlab at absamail.co.za
Tue Oct 4 21:33:29 CEST 2005


Dan Parnetewrote:-
> I'm coming back on this problem. After 40-50 min of working in PET the
> system goes down in free memory and becomes very slow. Here is the heap
> track:
> 
>  147 AosModules.Module (256B total 37632B)
>    47 AosInterrupts.HandlerList (32B total 1504B)
>    26 AosActive.Timer (32B total 832B)
> .....

Sven wrote:-
> I could reproduce the problem you described below. The memory allocated =
> when opening a PET instance is not freed up completely by the garbage =
> collector when closing PET. Other applications seem not to be affected =
> (I didn't test that many, though).
> So either the GC has a bug and does not collect all dynamic data =
> structures that were referenced only by PET (or modules imported by =
> PET), or there are memory references still pointing to some of these =
> structures after PET is closed. "S.Free PET" didn't help, but PET =
> imports a lot of other modules.
> I've extended the Performance Monitor (WMPerfMon.Mod) to display =
> information about occupied memory more reasonable using the information =
> from both AosHeap.Mod and AosMemory.Mod (crazy fresh 30.09.2005). It =
> perfectly shows the problem - just open and then close several instances =
> of PET, that's enough to produce the problem.
> 
Because I have to *USE* my system, I'm sticking to NO and just 
looking out the corner of my eyes at what's happening with BB/Aos.

I'm guessing that much of NO is transplanted into BB/Aos ?
I'm always interested in 'deep', often subtle faults.
I'm still hoping to solve the dial/ppp fault which I can 'unlock'
  [also] by repeated Ctrl/Break: which apparently interrupts the
  tasking cycle.

A previous query re. compiler and trap which the author
suggested was solved [no trap] by removing the compiler
constraint [ array out of bounds I think], is possibly only 
moving the problem to a more difficult 'place to find' ?

Perhaps others would also like the debugging and fixing
of this gc error to be openly discussed; if only for educational
value ?

== Chris Glur.




More information about the Oberon mailing list