Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2003-03

Matrix library for FPC

18 messages · 7 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Preben Mikael Bohn

I guess this is slightly off-topic as it is not directly fpc-specific, but here it goes anyway:

Are there any good matrix/vector-libraries for FPC (should be compilable with fpc)? It is essential that it can handle special matrices (doubly-bordered block-diagonal, sparse, etc) and that these matrices can be arbitrarily long (i.e. files should be used automagically for large matrices). Preferrably it should use objects... :-)

Best regards Preben

paradice
to Preben Mikael Bohn

Hi all -

Is there anyway I can tell exactly which procedures/functions/methods etc. are being discarded when I build an EXE with smartlinking (Win32 or DOS)??? I'm not concerned that it is doing anything wrong (I've never had a problem with it at all) but I would just like to see how much of my units' code is actually being used in a given application... thanks!

Show quoted text 29 lines
-----Original Message----- From: Behalf Of Preben Mikael Bohn Sent: Wednesday, 19 March 2003 2:55 a.m. To: Subject: [fpc-pascal]Matrix library for FPC I guess this is slightly off-topic as it is not directly fpc-specific, but here it goes anyway: Are there any good matrix/vector-libraries for FPC (should be compilable with fpc)? It is essential that it can handle special matrices (doubly-bordered block-diagonal, sparse, etc) and that these matrices can be arbitrarily long (i.e. files should be used automagically for large matrices). Preferrably it should use objects... :-) Best regards Preben _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal
paradice
to Preben Mikael Bohn: I guess this is slightly off-topic as it is not directly fpc-specific, but here it goes…

Hi again -

another question; what is the best way to "fail" a constructor call? For example, I have a constructor "timage.loadimage()", and I want it to return "nil" if it encounters a problem (e.g. the file name doesn't exist). My example program is this:

type
   mytestclass    =  class
      bobbob      :  longint;
      constructor    create;
   end;
constructor mytestclass.create;
begin
   inherited create;
   free; // *** what do I put here?
   result := nil;
end;
var
   bob   :  mytestclass;
begin
   bob := nil;
   writeln('Memavail before: ',memavail);
   bob := mytestclass.create;
   writeln('Memavail after : ',memavail);
   writeln('Bob assigned? ',assigned(bob));
end.

The problem is where the *** is marked; I don't know what to place there to do everything properly. If I use "free" then there is no memory leak, but "bob" is "assigned" (the result:=nil does nothing). I also tried "fail" (as I remember seeing it in the docs somewhere but I couldn't find it again) - if I do this bob returns "nil" as expected but there is a memory leak. Using both of them together doesn't help me either. Is there a legal way to do this?

Peter Vreman
to paradice: Hi all - Is there anyway I can tell exactly which procedures/functions/methods etc. are…
Show quoted text 10 lines
Hi all - Is there anyway I can tell exactly which procedures/functions/methods etc. are being discarded when I build an EXE with smartlinking (Win32 or DOS)??? I'm not concerned that it is doing anything wrong (I've never had a problem with it at all) but I would just like to see how much of my units' code is actually being used in a given application... thanks!

Add -k-M to let ld generate a map file

Lee, John

Here's a program I wrote some time ago (it's been tested with with win32,go32v2 & linux) to help you to analyse the map file - I didn't find it easy! And a readme...

HTH

John

Earlier message 22 lines
-----Original Message----- From: Peter Vreman Sent: Wednesday, March 19, 2003 09:27 To: Subject: Re: [fpc-pascal]Smartlinking question > Hi all - > > Is there anyway I can tell exactly which procedures/functions/methods etc. > are being discarded when I build an EXE with smartlinking (Win32 or > DOS)??? > I'm not concerned that it is doing anything wrong (I've never had a > problem > with it at all) but I would just like to see how much of my units' code is > actually being used in a given application... thanks! > Add -k-M to let ld generate a map file
paradice
to Peter Vreman: Use fail :-)
Show quoted text 9 lines
> Hi again - > > another question; what is the best way to "fail" a constructor call? For > example, I have a constructor "timage.loadimage()", and I want it to > return > "nil" if it encounters a problem (e.g. the file name doesn't exist). My Use fail :-)

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)

Heap dump by heaptrc unit
13 memory blocks allocated : 224/248
11 memory blocks freed : 188/208
2 unfreed memory blocks : 36
True heap size : 20000000 (64 used in System startup) True free heap : 19999792
Should be : 19999800
Call trace for block 0x0040AEA4 size 24
0x004051AF
0x00401ECC MYTESTCLASS__CREATE, line 13 of e:/projects/tests/classtst.pp 0x00401DC6 main, line 26 of e:/projects/tests/classtst.pp 0x00401059
Call trace for block 0x0040AEF4 size 12
0x00405176
0x00401ECC MYTESTCLASS__CREATE, line 13 of e:/projects/tests/classtst.pp 0x00401DC6 main, line 26 of e:/projects/tests/classtst.pp 0x00401059

Show quoted text 6 lines
_______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Peter Vreman
to paradice
Show quoted text 37 lines
> > > Hi again - > > > > another question; what is the best way to "fail" a constructor call? > For > > example, I have a constructor "timage.loadimage()", and I want it to > > return > > "nil" if it encounters a problem (e.g. the file name doesn't exist). > My > > Use fail :-) 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) Heap dump by heaptrc unit 13 memory blocks allocated : 224/248 11 memory blocks freed : 188/208 2 unfreed memory blocks : 36 True heap size : 20000000 (64 used in System startup) True free heap : 19999792 Should be : 19999800 Call trace for block 0x0040AEA4 size 24 0x004051AF 0x00401ECC MYTESTCLASS__CREATE, line 13 of e:/projects/tests/classtst.pp 0x00401DC6 main, line 26 of e:/projects/tests/classtst.pp 0x00401059 Call trace for block 0x0040AEF4 size 12 0x00405176 0x00401ECC MYTESTCLASS__CREATE, line 13 of e:/projects/tests/classtst.pp 0x00401DC6 main, line 26 of e:/projects/tests/classtst.pp 0x00401059

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.

Anton Tichawa
to Peter Vreman
you wrote 48 lines
>> > Hi again - >> > >> > another question; what is the best way to "fail" a constructor call? >> >> For >> >> > example, I have a constructor "timage.loadimage()", and I want it to >> > return >> > "nil" if it encounters a problem (e.g. the file name doesn't exist). >> >> My >> >> Use fail :-) > > 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) > > Heap dump by heaptrc unit > 13 memory blocks allocated : 224/248 > 11 memory blocks freed : 188/208 > 2 unfreed memory blocks : 36 > True heap size : 20000000 (64 used in System startup) > True free heap : 19999792 > Should be : 19999800 > Call trace for block 0x0040AEA4 size 24 > 0x004051AF > 0x00401ECC MYTESTCLASS__CREATE, line 13 of > e:/projects/tests/classtst.pp > 0x00401DC6 main, line 26 of e:/projects/tests/classtst.pp > 0x00401059 > Call trace for block 0x0040AEF4 size 12 > 0x00405176 > 0x00401ECC MYTESTCLASS__CREATE, line 13 of > e:/projects/tests/classtst.pp > 0x00401DC6 main, line 26 of e:/projects/tests/classtst.pp > 0x00401059 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. _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Maybe off-topic, but I thought about a constant static object at address 0 or so, in order to have the program stilll working when a constructor returns NIL (which has value 0). Would that be possible, e. g. under GNU-Linux?

anton tichawa.

----------

"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:

----------

paradice
to Peter Vreman: That is the exception frame that is left on the heap. I don't have the time to analyze…
Show quoted text 13 lines
> 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....

Peter Vreman
to paradice
Show quoted text 19 lines
> > 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

Peter Vreman
to Anton Tichawa: some months ago i had a discussion with a friend, converning global (static, absolute)…
Show quoted text 50 lines
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.

James Mills
to Michael Van Canneyt: Not in this case. For instance recursive routines will get in trouble. There is no way to…
Michael Van Canneyt wrote 78 lines
On Fri, 21 Mar 2003, Anton Tichawa wrote: > 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. Not in this case. For instance recursive routines will get in trouble. There is no way to know how deep the stack can be nested, so you cannot foresee this. Putting a limit on that is out of the question.

Agreed. If you put a limit on that, you will disallow algorithms that use resursive loops. There are many that do ...

cheers
James

Show quoted text 6 lines
Michael. _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Michael Van Canneyt
to Anton Tichawa: but also the power-switch, the data bus width, and the exception vectors in ROM now are…
Anton Tichawa wrote 70 lines
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.

Not in this case. For instance recursive routines will get in trouble. There is no way to know how deep the stack can be nested, so you cannot foresee this. Putting a limit on that is out of the question.

Michael.

Michael Van Canneyt
to Anton Tichawa: provided that noone has posted that before, and that safe email processing allows me to…
Anton Tichawa wrote 95 lines
On Friday 21 March 2003 14:02, you wrote: > On Fri, Mar 21, 2003 at 02:04:39PM +0100, Michael Van Canneyt wrote: > > On Fri, 21 Mar 2003, Anton Tichawa wrote: > > > 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. > > > > Not in this case. For instance recursive routines will get in trouble. > > There is no way to know how deep the stack can be nested, so you cannot > > foresee this. Putting a limit on that is out of the question. > > Agreed. If you put a limit on that, you will disallow algorithms that > use resursive loops. There are many that do ... provided that noone has posted that before, and that safe email processing allows me to post another argument, i'd say that: if memory is limited, unlimitedly recursive procedures are responsible to check stack space, aren't they? but if it's possible to define a maximum N, the check need be made only once, and the procedure will run faster. there's a kind of tradeoff between freedom and efficiency, isn't there?

No. If you want to define a maximum N, you need to allocate this at once to solve the problem. This will blow up your executable for any reasonable sized N even when it is not necessery.

also, if i remember right, anything that can be done recursively can also be done by applying a non-recursive algorithm.

This is not correct. This is only true for tail recursion.

Please don't try to convince us to do this; We won't, it's an ugly solution. Instead we'll try to fix the original problem.

Michael.

Anton Tichawa
to Peter Vreman: The reason why 1.1 has no leak is that it uses the stack to store the exception frames.…
you wrote 26 lines
>> > 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?

anton.

----------

"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
to Peter Vreman: It does not fix the problem, the frame is then still left on the stack. The allocation on…
you wrote 64 lines
> 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
to James Mills: Agreed. If you put a limit on that, you will disallow algorithms that use resursive…
you wrote 84 lines
On Fri, Mar 21, 2003 at 02:04:39PM +0100, Michael Van Canneyt wrote: > On Fri, 21 Mar 2003, Anton Tichawa wrote: > > 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. > > Not in this case. For instance recursive routines will get in trouble. > There is no way to know how deep the stack can be nested, so you cannot > foresee this. Putting a limit on that is out of the question. Agreed. If you put a limit on that, you will disallow algorithms that use resursive loops. There are many that do ...

provided that noone has posted that before, and that safe email processing allows me to post another argument, i'd say that:

if memory is limited, unlimitedly recursive procedures are responsible to check stack space, aren't they?

but if it's possible to define a maximum N, the check need be made only once, and the procedure will run faster. there's a kind of tradeoff between freedom and efficiency, isn't there?

also, if i remember right, anything that can be done recursively can also be done by applying a non-recursive algorithm. if that's true, recursive formulae are just comfortable, aren't they? that'd be a tradeoff between speed of programming and efficiency, wouldn't it?

anton.

----------

"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:

----------