Re: [fpc-pascal] methods of an object to create others objects
Op 2010-07-07 00:14, Andrew Brunner het geskryf:
>
> No, if the nesting is done properly you could guarantee that Obj2.Free
> would be called even if Obj1.Free failed with some exception.
No matter how many nested try..except or try..finally blocks you have, if
you are trying to free the instance and it causes an exception, you might
catch the exception, but you still can't free the object because it caused
an exception the first time, and will probably keep causing an exception
every time you try and free that instance. There is no way around that
memory leak because you simply can't free the instance.
Here is an example:
---[ memory_leak.pas ]
// compile with: fpc -gh -gl memory_leak.pas
program memory_leak;
{$mode objfpc}{$H+}
uses
Classes, SysUtils;
type
TMyObject = class(TObject)
private
FList: TList;
FMyName: string;
public
constructor Create;
destructor Destroy; override;
property MyName: string read FMyName write FMyName;
end;
{ TMyObject }
constructor TMyObject.Create;
begin
FList := TList.Create;
end;
destructor TMyObject.Destroy;
var
i, j: integer;
begin
i := 10;
j := 0;
j := i div j;
FList.Free;
inherited Destroy;
end;
var
obj: TMyObject;
{$R *.res}
begin
obj := TMyObject.Create;
try
try
obj.MyName := 'Me';
try
writeln(obj.MyName);
except
on E: Exception do
writeln('Oops'); // after this, the finally will still run
end;
finally
obj.Free;
end;
except
on E: Exception do
obj.Free; // this will just cause another exception
end;
end.
...and here is the output:
$ ./memory_leak
Me
An unhandled exception occurred at $004002C7 :
EDivByZero : Division by zero
$004002C7 line 32 of memory_leak.lpr
$0040FB2A
Heap dump by heaptrc unit
29 memory blocks allocated : 1071/1104
23 memory blocks freed : 819/848
6 unfreed memory blocks : 252
True heap size : 163840
True free heap : 162624
Should be : 162816
Call trace for block $7F2DBBB6D1E0 size 128
$00415CAA
$00411214
$00400CB0
$0040FB2A
$00400178
Call trace for block $7F2DBBB8DB40 size 40
$00411214
$00400CB0
$0040FB2A
$00400178
Call trace for block $7F2DBBB8DA80 size 20
$00462F7E
$00400CB0
$0040FB2A
$00400178
Call trace for block $7F2DBBB8D840 size 24
$0042DE9E
$00400216 line 23 of memory_leak.lpr
$0040034F line 43 of memory_leak.lpr
$00400178
Call trace for block $7F2DBBB853E0 size 16
$00400216 line 23 of memory_leak.lpr
$0040034F line 43 of memory_leak.lpr
$00400178
Call trace for block $7F2DBBB8D780 size 24
$0040034F line
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
Op 2010-07-07 03:32, Martin het geskryf: > > And in the 2nd case, mem leaks are no worry => the app is going to be > closed, mem will be freed by the OS. >[...snip...] > > The whole memory management could be corrupted. Trying to free > memory could just cause more and more exceptions. That is exactly what I was trying to explain to Andrew. If freeing an instance is what caused the exception, no amount of try..except or try..finally blocks will help you - you still can't free the instance, so better notify the user to try and save, then quit the app and start again. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
Op 2010-07-07 05:25, Andrew Brunner het geskryf: > So just make sure the Destroy methods free what they are supposed to free. What if that was the cause of the exception in the first place. :-) eg: Exception occurs in the destructor before all resource could be freed. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
On Wed, Jul 7, 2010 at 2:09 AM, Graeme Geldenhuys wrote: > Op 2010-07-07 03:32, Martin het geskryf: >> >> And in the 2nd case, mem leaks are no worry => the app is going to be >> closed, mem will be freed by the OS. >>[...snip...] >> >> The whole memory management could be corrupted. Trying to free >> memory could just cause more and more exceptions. > > > That is exactly what I was trying to explain to Andrew. If freeing an > instance is what caused the exception, no amount of try..except or > try..finally blocks will help you - you still can't free the instance, so > better notify the user to try and save, then quit the app and start again. > Ok. I think I understand the discrepancy in our reasoning. The issue is when exceptions are raised during Obj.Free. I think it would help if you would assume that all exceptions raised in Obj.Free were handled - since my assertion is all developers using a non-managed platform like FPC. I'm saying that because if memory is allocated, and deallocated you will not blow-out the memory manager in FPC. Meaning, if you catch your exceptions FATAL errors will not even occur and there will be NO NEED to worry about restarting an application. Its a clean way of thinking. I have no worries. When I call Obj.Free it can raise exceptions, and still recover to the calling methods - whether we are talking about ObjX.free or ObjX.DoSomething. My basic point is that just because an exception is raised does not mean the method will blow-out. It will be handled. LOL... With exception handling (often nested) where required. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
On Wed, Jul 7, 2010 at 9:30 AM, Andrew Brunner wrote: > Ok. I think I understand the discrepancy in our reasoning. The issue > is when exceptions are raised during Obj.Free. I think it would help > if you would assume that all exceptions raised in Obj.Free were > handled - since my assertion is all developers using a non-managed > platform like FPC. I'm saying that because if memory is allocated, > and deallocated you will not blow-out the memory manager in FPC. > Meaning, if you catch your exceptions FATAL errors will not even occur > and there will be NO NEED to worry about restarting an application. But, even using nested handled the memory may be impaired so, you need restarting the application. > Its a clean way of thinking. I have no worries. When I call Obj.Free > it can raise exceptions, and still recover to the calling methods - > whether we are talking about ObjX.free or ObjX.DoSomething. > > My basic point is that just because an exception is raised does not > mean the method will blow-out. It will be handled. LOL... With > exception handling (often nested) where required. Your application will continue running, if that is what you meant when you said not to worry. But the memory may not be 100%, even using nested handled. MD. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
On 07/07/2010 13:30, Andrew Brunner wrote: On Wed, Jul 7, 2010 at 2:09 AM, Graeme Geldenhuys wrote: Op 2010-07-07 03:32, Martin het geskryf: And in the 2nd case, mem leaks are no worry => the app is going to be closed, mem will be freed by the OS. [...snip...] The whole memory management could be corrupted. Trying to free memory could just cause more and more exceptions. That is exactly what I was trying to explain to Andrew. If freeing an instance is what caused the exception, no amount of try..except or try..finally blocks will help you - you still can't free the instance, so better notify the user to try and save, then quit the app and start again. Ok. I think I understand the discrepancy in our reasoning. The issue is when exceptions are raised during Obj.Free. I think it would help if you would assume that all exceptions raised in Obj.Free were handled - since my assertion is all developers using a non-managed platform like FPC. I'm saying that because if memory is allocated, and deallocated you will not blow-out the memory manager in FPC. The initial exception does not have to be in Free or Destroy at all. If somewhere in the code a statement as follows is executed, then all bets are off UninitializedPointerToRandomAddress := SomeValue; You may have changed any other structure to anything. There is no waty to predict if the app can even continue to run, it can cause any amount of subsequent crashes. It could have destroyed the memory-managers structures of which memory is allocated. It could have modified other pointers, that now point to random addresses, it could have hit the stack and modified the return address, With an exception like this, the rule is: Do as little as you can. Everything you do can make it worse. Call a function that relies on as little data as possible, and tries to simple save all user-data to an emergency file. Then exit Meaning, if you catch your exceptions FATAL errors will not even occur and there will be NO NEED to worry about restarting an application. Fatal errors don't alwasy need an exception in order to occur. They can occur even if all exceptions are caught. They occur because with growing complexity of a software, the chances grow that the developper will introduce an error in the code. If you argue that is not going to happen to you, then my congratulations. You must get a rather huge salary (million?), because if you look at the list of exploits in professional software, you will see that it happens to every other professional developper. Its a clean way of thinking. I have no worries. When I call Obj.Free it can raise exceptions, and still recover to the calling methods - whether we are talking about ObjX.free or ObjX.DoSomething. My basic point is that just because an exception is raised does not mean the method will blow-out. It will be handled. LOL... With exception handling (often nested) where required. No of course an exception doe snot mean, that all is gone. But you always have to know what the code that threw the exception was supposed to do. If I write my own code then some methods I wrote are not expected to raise an exception (including they do not call any code that could ). Then there is no need for try blocks around this code, because if it does throw an exception, then it is an exception that can not be recovered. As I said in my initial mail: - There are exceptions that are intentionally risen. They can and should be handled correctly. - There are exception that stem from errors in the implementation, they are not excpeted, and there is no way to assert how much dameage they have done This mail was only about the 2nd kind of exception Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
On 07/07/2010 13:54, Martin wrote: On 07/07/2010 13:30, Andrew Brunner wrote: Ok. I think I understand the discrepancy in our reasoning. The issue is when exceptions are raised during Obj.Free. I think it would help UninitializedPointerToRandomAddress := SomeValue; You may have changed any other structure to anything. There is no waty to predict if the app can even continue to run, it can cause any amount of subsequent crashes. It could have destroyed the memory-managers structures As I said in my initial mail: - There are exceptions that are intentionally risen. They can and should be handled correctly. - There are exception that stem from errors in the implementation, they are not excpeted, and there is no way to assert how much dameage they have done This mail was only about the 2nd kind of exception And I forgot to return to the initial point While object.free can throw an exception, in most cases it is not expected to do so. That means with most objects (at least those, that I use, or write), if an exception occurs during destruction, then that clearly is an exception of the 2nd kind. Therefore an exception that occurs in free/destroy (in my apps) indicates a none recoverable situation => and hence no more worries about leaks => only worries about saving as much userdata as possible. so here is the code again obj1 := nil; obj2 := nil; try obj1 := tobj1.create; obj2 := obj1.createObj; //... finally obj1.free; obj2.free; end; if " obj1.free; " crashes, then yes obj2 is not going to be released. But as explained in this and my last mail: It should not be attempted to be released. if " obj1.free; " crashed, then the state of the app is unknown, anything that the app does from now on could cause more havoc. trying to free obj2 could destroy value-able user-data that otherwhise may still have been saved to a file. I have an object, of which I know that it can throw a recoverable exception within it's destructor, then I need nested try blocks. Otherwise (which in my case is the rule) I do not need nested try. Martin Disclaimer: Having said that most objects are not excected to raise an exception in destruction => there are valid exception, and one has to know them, and act on them. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
On Wed, Jul 7, 2010 at 9:54 AM, Martin wrote: > > [...snip...] > > With an exception like this, the rule is: Do as little as you can. > Everything you do can make it worse. Call a function that relies on as > little data as possible, and tries to simple save all user-data to an > emergency file. Then exit Here we have a big problem if the program is a web app using FastCGI. In this case, what we do? MD. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
On Wed, Jul 7, 2010 at 8:05 AM, Martin wrote: > > if " obj1.free; " crashes, then yes obj2 is not going to be released. But as > explained in this and my last mail: It should not be attempted to be > released. > Martin, I can't disagree more. I find it completely ludicrous that if obj1.free raises an exception you should just trow the baby out with the bath water. If Obj1.Free raised an exception because a disk drive was unmounted... Inspect the log... Handle the exception... And fix the problem. Future instances will be handled and all is good. It is my belief that the notion of skipping exception handling and restarting an application is very bad practice. > if " obj1.free; " crashed, then the state of the app is unknown, anything > that the app does from now on could cause more havoc. trying to free obj2 > could destroy value-able user-data that otherwhise may still have been saved > to a file. LOL. If something inside Obj1.free HAD EXCEPTION handling you would catch the error and understand what caused it. procedure TObj1.Free; begin Disk1.Unmount; <<< The disk object is missing now b/c a network failure; Inherited Destroy; end; procedure TObj1.Free; begin Try Disk1.Unmount; Except On E:Exception do begin // Some case stuff here end; end; Inherited Destroy; end; In my example... Your code would blow out an application. With my exception handling the app would continue on as normal with no problems. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
On Wed, Jul 7, 2010 at 10:05 AM, Martin wrote: > On 07/07/2010 13:54, Martin wrote: >> >> On 07/07/2010 13:30, Andrew Brunner wrote: >>> >>> Ok. I think I understand the discrepancy in our reasoning. The issue >>> is when exceptions are raised during Obj.Free. I think it would help > > >> >> UninitializedPointerToRandomAddress := SomeValue; >> >> You may have changed any other structure to anything. There is no waty to >> predict if the app can even continue to run, it can cause any amount of >> subsequent crashes. >> It could have destroyed the memory-managers structures > > >> >> As I said in my initial mail: >> - There are exceptions that are intentionally risen. They can and should >> be handled correctly. >> - There are exception that stem from errors in the implementation, they >> are not excpeted, and there is no way to assert how much dameage they have >> done >> >> This mail was only about the 2nd kind of exception >> > > And I forgot to return to the initial point > > While object.free can throw an exception, in most cases it is not expected > to do so. That means with most objects (at least those, that I use, or > write), if an exception occurs during destruction, then that clearly is an > exception of the 2nd kind. Therefore an exception that occurs in > free/destroy (in my apps) indicates a none recoverable situation => and > hence no more worries about leaks => only worries about saving as much > userdata as possible. > > so here is the code again > obj1 := nil; > obj2 := nil; > try > obj1 := tobj1.create; > obj2 := obj1.createObj; > //... > finally > obj1.free; > obj2.free; > end; > > > if " obj1.free; " crashes, then yes obj2 is not going to be released. But as > explained in this and my last mail: It should not be attempted to be > released. > > if " obj1.free; " crashed, then the state of the app is unknown, anything > that the app does from now on could cause more havoc. trying to free obj2 > could destroy value-able user-data that otherwhise may still have been saved > to a file. > > I have an object, of which I know that it can throw a recoverable exception > within it's destructor, then I need nested try blocks. Otherwise (which in > my case is the rule) I do not need nested try. > > Martin > > Disclaimer: > Having said that most objects are not excected to raise an exception in > destruction => there are valid exception, and one has to know them, and act > on them. Just one word, BRAVO! MD. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
On 07/07/2010 14:14, Marcos Douglas wrote: On Wed, Jul 7, 2010 at 9:54 AM, Martin wrote: [...snip...] With an exception like this, the rule is: Do as little as you can. Everything you do can make it worse. Call a function that relies on as little data as possible, and tries to simple save all user-data to an emergency file. Then exit Here we have a big problem if the program is a web app using FastCGI. In this case, what we do? Write as much info as you have to the servers log file => so you can fix the app. Return a 500 server error; that's what they are there for. For the rest I don't know FastCGI good enough. But it needs a way to tell the server that t need's to be reloaded => e.g under apache it is common that each apache process is reused a certain amount of times => If a bad crash has happened then this process needs to be replaced. It's good that in apache it's threads (or at least last time I check3ed) and not threads => if it was threads, you needed to kill the whole server, with processes, you only replace one child process. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
On 07/07/2010 14:25, Andrew Brunner wrote: On Wed, Jul 7, 2010 at 8:05 AM, Martin wrote: if " obj1.free; " crashes, then yes obj2 is not going to be released. But as explained in this and my last mail: It should not be attempted to be released. Martin, I can't disagree more. I find it completely ludicrous that if obj1.free raises an exception you should just trow the baby out with the bath water. If Obj1.Free raised an exception because a disk drive was unmounted... Inspect the log... Handle the exception... And fix the problem. Future instances will be handled and all is good. It is my belief that the notion of skipping exception handling and restarting an application is very bad practice. Had you only read to the end of my mail. You are deliberately ignoring part of what I wrote and the blame me for the remainder being incomplete? I clearly stated that there are cases where "free" can raise a valid exception, and that the developper has to know this cases, and handle them (with nested try blocks). But I also wrote that (for me) the rule is that most "free" are not expected to do so (that may of course be totally different in your code). Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
On 7 July 2010 15:25, Andrew Brunner wrote: > > procedure TObj1.Free; > begin > Disk1.Unmount; <<< The disk object is missing now b/c a network failure; > Inherited Destroy; > end; > > procedure TObj1.Free; > begin > Try > Disk1.Unmount; > Except > On E:Exception do begin > // Some case stuff here > end; > end; > Inherited Destroy; > end; > > In my example... Your code would blow out an application. With my > exception handling the app would continue on as normal with no > problems. With the exception of a possible memory leak in case Disk1.Unmount was supposed to free up some resources. And if your app is something that runs 24/7, that is a *huge* problem! Eventually you will run out of memory and the whole thing will come crumbling down (and maybe even cause more damage). -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
On Wed, Jul 7, 2010 at 8:37 AM, Graeme Geldenhuys wrote: >> procedure TObj1.Free; >> begin >> Try >> Disk1.Unmount; >> Except >> On E:Exception do begin >> // Some case stuff here >> end; >> end; >> Inherited Destroy; >> end; >> > > With the exception of a possible memory leak in case Disk1.Unmount was > supposed to free up some resources. And if your app is something that > runs 24/7, that is a *huge* problem! Eventually you will run out of > memory and the whole thing will come crumbling down (and maybe even > cause more damage). > Grame, no more caveats. If Unmount had memory that needed to be released then the same methodology stands. Disk1.Unmount was placed there to prove a point. That w/o handling Obj2.Free would never be called in context (the outstanding proposed example). As far as *HUGE* problem. Having to restart my server would be huge.. Especially in high scale, high available production environments. Having a handle in place that says CATCH STUFF HERE like Save to SQL server (if your needing to write to disk). The example I introduced is a good one. Ignoring the exception will indeed cause a fatal error. Handling the exception is the best practice here. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
On Wed, Jul 7, 2010 at 8:34 AM, Martin wrote: > Had you only read to the end of my mail. You are deliberately ignoring > part of what I wrote and the blame me for the remainder being incomplete? > > I clearly stated that there are cases where "free" can raise a valid > exception, and that the developper has to know this cases, and handle them > (with nested try blocks). > > But I also wrote that (for me) the rule is that most "free" are not expected > to do so (that may of course be totally different in your code). Martin, I didn't get to the end of your email because I find that first major part - part and parcel of why Delphi failed as a language. It became unviable because exception handling and blow-outs. Which in turn were caused by sloppy ideologies such as the standing notion here... Which is to let the blow-out occur and move on. Garbage collection was the solution to this problem. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
On 7 July 2010 15:44, Andrew Brunner wrote: > > As far as *HUGE* problem. Having to restart my server would be huge.. > Especially in high scale, high available production environments. You don't have to restart the server (hardware), only the application or service (app server software). As in a busy environment that could be troublesome too, but a lot less troublesome than the whole server (hardware) doing down because it ran out of memory. Get it? If not, I don't care at point... enough said on the topic. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] methods of an object to create others objects
Hello FPC-Pascal, Wednesday, July 7, 2010, 3:48:13 PM, you wrote: AB> Martin, I didn't get to the end of your email because I find that AB> first major part - part and parcel of why Delphi failed as a language. AB> It became unviable because exception handling and blow-outs. Which AB> in turn were caused by sloppy ideologies such as the standing notion AB> here... Which is to let the blow-out occur and move on. Garbage AB> collection was the solution to this problem. It's impossible to write a dogma about exceptions, some must be handled, some could or could not be handled. Expected exceptions like a conversion string to number should be handled and processed in that way to recover from them (they are recoverable). If an exception is recoverable (program state can be passed from unestable to stable again) it should be handled and processed. If the handling does not garantee the stability the best option is to save the information that can be safelly stored or processed and terminate the process as soon as possible. It's not a matter of ideology, is a matter of stability. Unexpected exceptions should terminate the program as soon as possible with trying to save as much as possible. Even in some processes an unexpected exception should revert the program to the previous stable state (if possible) and discard all information in memory to avoid the possibility of corrupted information. -- Best regards, José ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
On Wed, Jul 7, 2010 at 10:28 AM, Martin wrote: > On 07/07/2010 14:14, Marcos Douglas wrote: >> >> Here we have a big problem if the program is a web app using FastCGI. >> In this case, what we do? >> > > Write as much info as you have to the servers log file => so you can fix the > app. > Return a 500 server error; that's what they are there for. Ok, I know :) I talked about the mem state! Let's continue... > For the rest I don't know FastCGI good enough. But it needs a way to tell > the server that t need's to be reloaded => e.g under apache it is common > that each apache process is reused a certain amount of times => If a bad > crash has happened then this process needs to be replaced. > > It's good that in apache it's threads (or at least last time I check3ed) and > not threads => if it was threads, you needed to kill the whole server, with > processes, you only replace one child process. Well... I think CGI gateway is a good way. If the real app (FCGI) have troubles, I can change the URL that the CGI (gateway) uses to call the real app and to point to another app (in other server, e.g.). What do you think about it? MD. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
On Wed, Jul 7, 2010 at 10:44 AM, Andrew Brunner wrote: > > Grame, no more caveats. If Unmount had memory that needed to be > released then the same methodology stands. Disk1.Unmount was placed > there to prove a point. That w/o handling Obj2.Free would never be > called in context (the outstanding proposed example). > > As far as *HUGE* problem. Having to restart my server would be huge.. > Especially in high scale, high available production environments. > Having a handle in place that says CATCH STUFF HERE like Save to SQL > server (if your needing to write to disk). The example I introduced > is a good one. Ignoring the exception will indeed cause a fatal > error. Handling the exception is the best practice here. Nobody said handling exceptions is bad practice! I understand that there are cases that have nothing to do when an exception (unexpectedly) is generated. We can not foresee everything. MD. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[2]: [fpc-pascal] methods of an object to create others objects
On Wed, Jul 7, 2010 at 11:35 AM, José Mejuto wrote: > Hello FPC-Pascal, > > Wednesday, July 7, 2010, 3:48:13 PM, you wrote: > > AB> Martin, I didn't get to the end of your email because I find that > AB> first major part - part and parcel of why Delphi failed as a language. > AB> It became unviable because exception handling and blow-outs. Which > AB> in turn were caused by sloppy ideologies such as the standing notion > AB> here... Which is to let the blow-out occur and move on. Garbage > AB> collection was the solution to this problem. > > It's impossible to write a dogma about exceptions, some must be > handled, some could or could not be handled. Expected exceptions like > a conversion string to number should be handled and processed in that > way to recover from them (they are recoverable). > > If an exception is recoverable (program state can be passed from > unestable to stable again) it should be handled and processed. If the > handling does not garantee the stability the best option is to save > the information that can be safelly stored or processed and terminate > the process as soon as possible. It's not a matter of ideology, is a > matter of stability. Unexpected exceptions should terminate the > program as soon as possible with trying to save as much as possible. > Even in some processes an unexpected exception should revert the > program to the previous stable state (if possible) and discard all > information in memory to avoid the possibility of corrupted > information. Exactly. I just wonder how you do in web apps that are not CGI. As I said earlier in an email here: http://lists.freepascal.org/lists/fpc-pascal/2010-July/025902.html ...but I guess that is to be reviewed, perhaps, in another thread. ;-) MD. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
> Well... I think CGI gateway is a good way. If the real app (FCGI) have > troubles, I can change the URL that the CGI (gateway) uses to call the > real app and to point to another app (in other server, e.g.). What do > you think about it? I think it would be worth discussing what can be done or at least start thinking about getting the memory manager not to blow-out any more. I really don't want to re-start server software just because a few apps (embedded in the service application) crash. Has anyone with experience with developing the memory manager been following? What about a separate discussion on application stabilization after an unhanded exception? That would be a necessity for at least my platform which is compiled with FPC - and certainly FCLWeb generated back-end apps too. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
On Wed, Jul 7, 2010 at 11:50 AM, Andrew Brunner wrote: >> Well... I think CGI gateway is a good way. If the real app (FCGI) have >> troubles, I can change the URL that the CGI (gateway) uses to call the >> real app and to point to another app (in other server, e.g.). What do >> you think about it? > > I think it would be worth discussing what can be done or at least > start thinking about getting the memory manager not to blow-out any > more. I really don't want to re-start server software just because a > few apps (embedded in the service application) crash. > > Has anyone with experience with developing the memory manager been > following? What about a separate discussion on application > stabilization after an unhanded exception? That would be a necessity > for at least my platform which is compiled with FPC - and certainly > FCLWeb generated back-end apps too. I think is a good idea. Do you uses FastCGI? MD. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[4]: [fpc-pascal] methods of an object to create others objects
Hello FPC-Pascal, Wednesday, July 7, 2010, 4:49:03 PM, you wrote: MD> Exactly. MD> I just wonder how you do in web apps that are not CGI. As I said MD> earlier in an email here: MD> http://lists.freepascal.org/lists/fpc-pascal/2010-July/025902.html MD> ...but I guess that is to be reviewed, perhaps, in another thread. ;-) I don't "do" :) because I do not have almost any experience in the web server world, but I'm quite sure you can let the exception scale up to the main process, which should end due unexpected exception and the watchdog restart it :-? In the other hand a simple "halt" should terminate the fastcgi application and this should force the web server to reload; or maybe fastcgi applications are modules ? -- Best regards, José ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[4]: [fpc-pascal] methods of an object to create others objects
On Wed, Jul 7, 2010 at 12:37 PM, José Mejuto wrote: > Hello FPC-Pascal, > > Wednesday, July 7, 2010, 4:49:03 PM, you wrote: > > MD> Exactly. > MD> I just wonder how you do in web apps that are not CGI. As I said > MD> earlier in an email here: > MD> http://lists.freepascal.org/lists/fpc-pascal/2010-July/025902.html > MD> ...but I guess that is to be reviewed, perhaps, in another thread. ;-) > > I don't "do" :) because I do not have almost any experience in the web > server world, but I'm quite sure you can let the exception scale up > to the main process, which should end due unexpected exception and the > watchdog restart it :-? In the other hand a simple "halt" should > terminate the fastcgi application and this should force the web server > to reload; or maybe fastcgi applications are modules ? Yes, you can use "halt" to stop webserver, but is not good. If exists others apps running in the same webserver, you will stop them too! FastCGI would be a separated app, running in memory. I think it may be a module too, but I would not do that. if you have an application that works separately from the web server, then it is easier to manage it (at least by hand, but I want to know how I do that automatically). MD. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
On 7 July 2010 15:09, Graeme Geldenhuys wrote: > On 7 July 2010 15:44, Andrew Brunner wrote: >> >> As far as *HUGE* problem. Having to restart my server would be huge.. >> Especially in high scale, high available production environments. > > You don't have to restart the server (hardware), only the application > or service (app server software). As in a busy environment that could > be troublesome too, but a lot less troublesome than the whole server > (hardware) doing down because it ran out of memory. Get it? If not, I > don't care at point... enough said on the topic. Indeed, it will drag the whole system down. That said (on linux, at least) when the program chomps too much memory, it'll get killed by the oom-killer anyway, so you're not much better off ignoring the exception. You can probably write a simple script to restart the app, as a fallback, after it sends an email to the admin containing the error message. Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
In our previous episode, Andrew Brunner said: > > Well... I think CGI gateway is a good way. If the real app (FCGI) have > > troubles, I can change the URL that the CGI (gateway) uses to call the > > real app and to point to another app (in other server, e.g.). What do > > you think about it? > > I think it would be worth discussing what can be done or at least > start thinking about getting the memory manager not to blow-out any > more. I really don't want to re-start server software just because a > few apps (embedded in the service application) crash. Well, first, there is the question if there is something to be fixed. (I myself think that plugging a few holes here and there once a quarter is might be worth avoiding the GC overhead and complexity. To be honest I never understood what all the fuzz about GC is about). But anyway, the question has been asked before, and I then archived the responses here: http://wiki.freepascal.org/garbage_collection For the specific case of web applications, there are other possibilities, since in general, one could try to exploit the knowledge that anything allocated during a request can be deallocated. Like the old mark/heap Of course somehow we would have to manage two heapmgrs then (for sessions and requests one each), and avoid polution the session heapmgr with request blocks. (e.g. by modifying ansistring etc helpers to avoid copy-on-write semantics) One could even regularly stream the session(s) over IPC to another addressspace (or flush to DB) once in a while and reset the session space too. > Has anyone with experience with developing the memory manager been > following? Not likely, since I haven't seen any insights in this thread. > What about a separate discussion on application > stabilization after an unhanded exception? No system is safe for that. Even a managed .NET or Java app can NIL some variable in some unlikely codepath, and every subsequent request can raise a NIL exception, resulting in a effectively defunct app. Moreover, GC only handles memory, not handles, DB connection etc. A real solution is not availble. > That would be a necessity for at least my platform which is compiled with > FPC - and certainly FCLWeb generated back-end apps too. It is not a problem of FPC, but of all applications in general. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
On Wed, 7 Jul 2010, Andrew Brunner wrote: Well... I think CGI gateway is a good way. If the real app (FCGI) have troubles, I can change the URL that the CGI (gateway) uses to call the real app and to point to another app (in other server, e.g.). What do you think about it? I think it would be worth discussing what can be done or at least start thinking about getting the memory manager not to blow-out any more. I really don't want to re-start server software just because a few apps (embedded in the service application) crash. Has anyone with experience with developing the memory manager been following? What about a separate discussion on application stabilization after an unhanded exception? That would be a necessity for at least my platform which is compiled with FPC - and certainly FCLWeb generated back-end apps too. Fcl-web ? Why ? 1. All fcl-web backends handle exceptions that occur in the web-request handler. 2. There is never an excuse for not freeing allocated resources, also in cases of exceptions. Such leaks must be identified, and plugged. Not worked around. FPC offers the heaptrace unit exactly for this. There is no way to allocate, use (and subsequently automatically free) memory associated with a web-request. One reason is simply string and class instance management, both of which inherently rely on a global heap manager without concept of 'context'. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
