[fpc-pascal]Constructor failing...

[Anton Tichawa]

On Friday 21 March 2003 13:09, you wrote:
> > On Friday 21 March 2003 12:29, you wrote:
> >> >> > But, when I use fail in my simple example program, it returns
> >> >>
> >> >> NIL okay but
> >> >>
> >> >> > the Heaptrace function tells me I have two unfreed memory blocks
> >>
> >> (36
> >>
> >> >> > bytes).
> >> >> > I can't see a memory leak anywhere else in that program, what
> >> >>
> >> >> could cause
> >> >>
> >> >> > this? (Heaptrace output is as follows: I am using FPC 1.0.6 btw)
> >> >>
> >> >> [snip heap dump]
> >> >>
> >> >> That is the exception frame that is left on the heap. I don't have
> >>
> >> the
> >>
> >> >> time to analyze what the cause is that the exception frame is not
> >> >> removed.
> >> >
> >> > It may be a bug in 1.0.6 which has subsequently been fixed. I
> >>
> >> downloaded
> >>
> >> > and
> >> > installed the 1.1 snapshots and compiled the same source code, and the
> >> > memory leak vanishes....
> >>
> >> The reason why 1.1 has no leak is that it uses the stack to store the
> >> exception frames. The real problem is still there, because exception
> >> stack
> >> is still not updated
> >
> > some months ago i had a discussion with a friend, converning global
> > (static,
> > absolute) variables. his point of view was that they're not necessary
> > when using oop; mine was, sometimes they're absoulutely necessary.
> >
> > if we have just one level of exception processing above normal program
> > execution (i. e. while an exception is being processed, no other
> > exception will gain control), we can use absolute variables for the
> > exception frame.
> >
> > it's even possible to define a fixed whole number of exception layers and
> > allocate absolute memory for N exception levels.
> >
> > that memory space would not get lost, as it can be saved by allocating
> > the 'normal' stack or 'normal' heap more tightly - the old system has to
> > reserve
> > exception spae implicitely on the stack or on the heap.
> >
> > what do you think about that?
>
> It does not fix the problem, the frame is then still left on the stack.
>
> The allocation on the heap has already been changed to allocation on the
> stack in 1.1, because hat is much faster. Using a predefined storage of N
> exception levels is adding a limit and that is something we want to
> prevent.

but also the power-switch, the data bus width, and the exception vectors in 
ROM now are limits. i think limits cannot be prevented, but they can be 
chosen knowingly, harmonic, and safe or so. every limit should include the 
overhead to overcome it later, as things get better.

----------

"Adas Methode war, wie sich zeigen wird, Tagträume in offenbar korrekte 
Berechnungen einzuweben."

Doris Langley Moore: Ada, Countess of Lovelace (London 1977).

----------

Anton Tichawa
Volkertstrasse 19 / 20
A-1020 Wien
mobil: +43 664 52 07 907
email: anton.tichawa at chello.at

----------