Re: [fpc-pascal] Generic way to pre-maturely exit TCustomApplication without memory leaks
On Wed, 12 Oct 2016, grouchysmurf wrote:
Hi.
Is there a way to pre-maturely halt TCustomApplication without causing
memory leaks?
Say, I have a code, where TH is a Class(TCustomApplication):
ph := TH.Create(Nil);
ph.Initialize;
ph.ProcessOptions;
ph.Run;
ph.Free;
When options are processed, it may happen the program needs to halt,
when provided with improper parameters, for example. In such a case,
I would call Help method:
Procedure TH.Help(ExitCode : Byte = 0; ErrStr : String = '');
Begin
{ do stuff }
Halt(ExitCode);
End;
Now, when this happens, ph is not freed, causing a minor memory leak.
I don't want that. Is there a way to terminate a program with Halt but
also making sure the memory has been freed properly?
Call Terminate and exit properly ?
TCustomApplication has an exitcode property which will set the global exit
code.
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic way to pre-maturely exit TCustomApplication without memory leaks
On 2016-10-12 20:37, grouchysmurf wrote: > Say, I have a code, where TH is a Class(TCustomApplication): > > ph := TH.Create(Nil); > ph.Initialize; > ph.ProcessOptions; > ph.Run; > ph.Free; I would also rewrite that with a try..finally as in: ph := TH.Create(nil) try ph.Initialize; ph.ProcessOptions; ph.Run; finally ph.Free; end; Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] The Next Release
On 10/13/16, Graeme Geldenhuys wrote: > Well, you have the source code. Simply change the version number > constant and rebuild it. ;-) The danger in that is that he might get so excited by the prospect of seeing a 4.0 version of fpc, that he may die of cardiac arrest in the process. Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic way to pre-maturely exit TCustomApplication without memory leaks
On 10/13/16, Michael Van Canneyt wrote:
> Call Terminate and exit properly ?
> TCustomApplication has an exitcode property which will set the global exit
> code.
AFAICS not in fpc 3.0.0
(TATCApp = class(TCustomApplication)
procedure TATCApp.OnExcept(Sender: TObject; E: Exception);
begin
writeln(Format('An exception has occurred of type %s, with
message:',[E.ClassName]));
writeln(Format('"%s"',[E.Message]));
writeln('The program will be termminated immediately.');
if (E is EInOutError) then Self.ExitCode := EInOutError(E).ErrorCode;
end;
air2.lpr(54,35) Error: identifier idents no member "ExitCode"
Probably you can set system.ExitCode before calling Terminate.
Bart
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic way to pre-maturely exit TCustomApplication without memory leaks
El 13/10/2016 a las 10:09, Graeme Geldenhuys escribió: > I would also rewrite that with a try..finally as in: > ph := TH.Create(nil) > try > ph.Initialize; > ph.ProcessOptions; > ph.Run; > finally > ph.Free; > end; May be I'm wrong, but I think that Halt(n) is a nuclear bomb, it closes the application almost on the current instruction, "finally" and "except" blocks are not executed. Nevertheless, Finalization blocks are executed. Anyway, I think that when the application is closed all the allocated memory is freed, memory leaks survive as long as the application is running. So wondering about what's in memory after a halt makes no sense, everything is freed. -- Saludos Santiago A. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] The Next Release
On 2016-10-13 09:58, Bart wrote: > The danger in that is that he might get so excited by the prospect of > seeing a 4.0 version of fpc, that he may die of cardiac arrest in the > process. Thankfully FPC comes with the following disclaimer. :-p “ This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ” Regards, Graeme ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] The Next Release
Of course, fpc might skip version 4 altogether. There is precedent. Winamp skipped version 4 with some lame excuse about not wanting to market "Winamp 4" skins ;-) On 13/10/16 10:56, Graeme Geldenhuys wrote: On 2016-10-13 09:58, Bart wrote: The danger in that is that he might get so excited by the prospect of seeing a 4.0 version of fpc, that he may die of cardiac arrest in the process. Thankfully FPC comes with the following disclaimer. :-p “ This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ” Regards, Graeme ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Smart link in FreeBSD multi-arch ?
On 2016-10-07 14:38, fredvs wrote: > FreeBSD has decided to stop FreeBSD 32 bit I just saw the FreeBSD 11.0 release announcement. In the "Availability" list, i386 is still mentioned. https://www.freebsd.org/releases/11.0R/announce.html Regards, Graeme ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic way to pre-maturely exit TCustomApplication without memory leaks
Am 13.10.2016 10:09 schrieb "Graeme Geldenhuys" < mailingli...@geldenhuys.co.uk>: > > On 2016-10-12 20:37, grouchysmurf wrote: > > Say, I have a code, where TH is a Class(TCustomApplication): > > > > ph := TH.Create(Nil); > > ph.Initialize; > > ph.ProcessOptions; > > ph.Run; > > ph.Free; > > I would also rewrite that with a try..finally as in: > > ph := TH.Create(nil) > try > ph.Initialize; > ph.ProcessOptions; > ph.Run; > finally > ph.Free; > end; > That won't help with Halt() however as that will "jump" directly to the unit finalization, ignoring any and all exception handlers along the way. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic way to pre-maturely exit TCustomApplication without memory leaks
On 2016-10-13 13:48, Sven Barth wrote: > That won't help with Halt() however as that will "jump" directly to the > unit finalization, ignoring any and all exception handlers along the way. Wow, that's a bit harsh. Overriding the whole meaning of the try..finally language feature. Then I would recommend NOT using Halt() for anything - its nasty. Regards, Graeme ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] The Next Release
due to the fact that there is no fixed time between major releases , one can wait maybe 10 years to see a next major release , just like gcc4 (2004-2014) , in the other hand gcc5 lives only 1 year . ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic way to pre-maturely exit TCustomApplication without memory leaks
Am 13.10.2016 15:07 schrieb "Graeme Geldenhuys" < mailingli...@geldenhuys.co.uk>: > > On 2016-10-13 13:48, Sven Barth wrote: > > That won't help with Halt() however as that will "jump" directly to the > > unit finalization, ignoring any and all exception handlers along the way. > > > Wow, that's a bit harsh. Overriding the whole meaning of the > try..finally language feature. Then I would recommend NOT using Halt() > for anything - its nasty. > You must not forget that it came from a time when Pascal didn't have exception handling. Nowadays it's indeed more often than not better not to use it due to the way it works. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic way to pre-maturely exit TCustomApplication without memory leaks
Hi. > Call Terminate and exit properly ? > TCustomApplication has an exitcode property which will set the global exit > code. This feature either undocumented or I am just too stupid to find it. Mind if I ask you to point me directly to the documentation? I believe it would have to be something as follows: ph.Terminate(ExitCode); ph.Free; if I am reading you correctly. Currently, if I call Terminate(1), it compiles with following error: Error: Wrong number of parameters specified for call to "Terminate" Would appreciate any help. Łukasz ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic way to pre-maturely exit TCustomApplication without memory leaks
Hi. > I would also rewrite that with a try..finally as in: Thanks. This is what I am planning to do eventually but as for now I am learning the ropes -- freepascal is kind of new to me and I am slowly learning its new features. Last Pascal I've been programming in was TP 6.0 with TurboVision. Oh, the memories... Łukasz ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic way to pre-maturely exit TCustomApplication without memory leaks
Hi. > Anyway, I think that when the application is closed all the allocated > memory is freed, memory leaks survive as long as the application is > running. So wondering about what's in memory after a halt makes no > sense, everything is freed. I am not very familiar with internals of system programming. Dump follows: Heap dump by heaptrc unit 73 memory blocks allocated : 1872/2048 70 memory blocks freed : 1733/1896 3 unfreed memory blocks : 139 True heap size : 327680 (96 used in System startup) True free heap : 327216 Should be : 327240 Call trace for block $014B4DC0 size 34 $00401A9A $00401BAE $0050005C $006F0072 $00720067 $006D0061 $00460020 $006C0069 Call trace for block $014AD820 size 17 $00401BAE $00401BAE Call trace for block $014DCBB8 size 88 $00401B8C Not that I know that to do with this data. Łukasz ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic way to pre-maturely exit TCustomApplication without memory leaks
El 13/10/2016 a las 15:07, Graeme Geldenhuys escribió: > On 2016-10-13 13:48, Sven Barth wrote: >> That won't help with Halt() however as that will "jump" directly to the >> unit finalization, ignoring any and all exception handlers along the way. > > Wow, that's a bit harsh. Overriding the whole meaning of the > try..finally language feature. Then I would recommend NOT using Halt() > for anything - its nasty. I only use it in the interpreting command line parameters phase. If there is an error, I display help and halt. And probably even in this cases I shouldn't, it's a dirty hack. -- Saludos Santiago A. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Smart link in FreeBSD multi-arch ?
Thanks Graeme. To know what is sent to the linker, there is the -s parameter. # fpc -XX -s test.pas This will compile the object and create a script file for the linker. Here the script with -XX parameter: /usr/bin/ld -b elf32-i386-freebsd -m elf_i386_fbsd *--gc-sections* -s -L. -0 ./test ./link.res If seems to me then that *--gc-sections* has to do with smart-link too. >From site https://sourceware.org/binutils/docs/ld/Options.html: --gc-sections --no-gc-sections Enable garbage collection of unused input sections. It is ignored on targets that do not support this option. The default behaviour (of not performing this garbage collection) can be restored by specifying `--no-gc-sections' on the command line. Note that garbage collection for COFF and PE format targets is supported, but the implementation is currently considered to be experimental. `--gc-sections' decides which input sections are used by examining symbols and relocations. The section containing the entry symbol and all sections containing symbols undefined on the command-line will be kept, as will sections containing symbols referenced by dynamic objects. Note that when building shared libraries, the linker must assume that any visible symbol is referenced. Once this initial set of sections has been determined, the linker recursively marks as used any section referenced by their relocations. See `--entry' and `--undefined'. This option can be set when doing a partial link (enabled with option `-r'). In this case the root of symbols kept must be explicitly specified either by an `--entry' or `--undefined' option or by a ENTRY command in the linker script. ___ There, in FreeBSD forum, they do not agree. https://forums.freebsd.org/threads/57931/page-3 Fre;D - Many thanks ;-) -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Smart-link-in-FreeBSD-multi-arch-tp5726375p5726567.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] teventobject.create fails with error 161
Hi, Just wondering if anyone has any ideas.
I am using FPC 3.0 by the way.
Anyway, I am using a third party SFTP server lib and it creates a thread
inherited from tthread and in the create event of the tthread descendant it
does this:
(It uses this thread to read and write data on the socket)
FDataAvailable := TEvent.Create(nil, True, False, ''); //tevent maps to
teventobject
{$IFDEF MSWINDOWS}
lasterr:=GetLastError;
if (lasterr <> 0) then
begin
msg:=SysErrorMessage(lasterr);
SetLastError(NO_ERROR); //<--I added this an attempt to recover
from the error
raise Exception.Create(SCannotCreateEvent+':'+msg);
end;
{$ENDIF}
after the call to FDataAvailable it always has a handle pointer, but what
seems very random like GetLastError will return non 0 always with code 161
which is invalid path name.
When this occurs all new connections will fail, the process becomes useless
and I have stop it.
If I remove the call to getlasterror and ignore it, the threads go into
100% cpu usage in the while loops used to read or write when the error does
occur.
Users can actually connect but not transfer any data.
Also when I compile as 64bit the odds of this happening go way down and I
can sometimes transfer 1 files before it happens, on 32bit it happens
much more frequently.
Apparently this is only a issue on Windows hence the compiler defs for
MSWINDOWS.
I did report this issue to the vendor and they said they are looking into
it but that could take months.
Anyone have any ideas one why teventobject.create is failing? Even though
it does have a hander pointer is it possible it's somehow a bad pointer?
This happens on windows 7 through 10 and even on PCs with lots of
resources(32gb ram, SSD hard drive and no corporate bloatware.
Thanks,
T
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
