Re: [fpc-pascal] with no if assigned() there are bugs

[Lars]

On Wed, September 21, 2016 6:27 am, Pierre Free Pascal wrote:
> There is also the -gc option:
> -gcGenerate checks for pointers
>
>
> This is another debugging option, that is not used very often,


I could not find this option in the Lazarus options under debugging or any
other tab... maybe it is not used often enough that Lazarus missed putting
it in a compiler option configuration... or I may have missed it.

I think this is a good check to have So in Lazarus must I make my own
custom option, or is it hidden somewhere where I cannot see it?

I should post this to lazarus list: in this case do I double post to both
freepascal list and lazarus list, or better to just post a message to one
list?

Thanx
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] with no if assigned() there are bugs

[Lars]

> On 2016-09-21 13:27, Pierre Free Pascal wrote:
>
> There is also the -gc option:
> -gcGenerate checks for pointers
>


I was going to add to my original post "sorry if this feature already
exists, or something similar".

Now I have to see what Delphi offers, as I use fpc and delphi and need
this check on both systems!


p.s. unrelated off topic: someone said that Delphi Berlin Starter only
works on Windows 10. I found it worked fine on my Windows 7, FYI.  But I
think the free offer (download) is over, or if not, shortly.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] with no if assigned() there are bugs

[Jonas Maebe]

Pierre Free Pascal wrote:
>   As the fix is not cpu specific, I enabled the -gc option
> for all linux systems in trunk, but this is untested.

Please never do that. I am the one that disabled this specific option in
the past (and others too) because they had never been tested and were
often broken. Enabling and releasing options without testing them at all
just results in user frustration (because they rightfully expect that
when we officially release something, it has at the very least been
tested by one person).

Additionally, -gc does not work at all as soon as you link to an
external library and access memory that has been allocated by this
external library. As a result, I would strongly discourage using it at
all, except in pure FPC programs.


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Smart link in FreeBSD multi-arch ?

[fredvs]

Hello.

I will try to explain the problem...

In a multi-arch system (64 bit system that can run 32 bit apps too) FreeBSD
64, there is problem if a fpc 32 bit application was compiled with smart
link (-XX).

This because FreeBSD call *ld-elf32.so.1* for 32 bit applications, in place
of *ld-elf.so.1* in his multi-arch sytsem. 

On mono-arch system (32 bit or 64 bit), FreeBSD call ld-elf.so.1 (that for
32 or 64 bit).

So, to resume, with smart link (-XX) in a 32 bit FreeBSD app, the link would
search first for *ld-elf32.so.1* and if not exist, search for *
ld-elf.so.1*.

And it is not the case, with -XX, the program search only for *ld-elf.so.1*,
even if it is on a multi-arch system.

Hope somebody has understood.

Thanks.

Fre;D





-
Many thanks ;-)
--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Smart-link-in-FreeBSD-multi-arch-tp5726375.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] polYdev release 1.0 with fpc as superstar.

[fredvs]

Hello.

polYdev release 1.0 is ready to download.

polYdev is a multiarch FreeBSD 10.3 operating system.

Thanks to his emulators, polYdev is able to compile and run applications for
FreeBSD 64/32, Linux 64/32 and Windows 32 bit.

No virtual machines needed, the compilations are fast and use the native
compiler of each system.

polYdev is shipped/configured with fpc 3.0.0 for FreeBSD 64/32, Linux 64/32,
and Windows 32 bit.

Here how to install polYdev:

- Download the release from here: 
  https://mega.nz/#!fwwRkLrQ

  This is the key Mega will ask:
  !0Pw4NOrCbiCffB3cZ7IrhY52cmaAp3Oa-jU99y5hNPY

- Load and run the iso.

- If you use a virtual machine, 2 gigas of ram are needed.

- When the system is installed on device, install programs via menu "Install
programs".
  This will install fpc and all the needed libraries for poly-compiling.

- In /usr/local/share/ideu/prj_test_multisys/, there are demos of fpGUI and
MSEgui poly-system.

  You may test it with ideU, all is pre-configured.
 
  The source of all fpc fpGUI and MSEgui applications in the disto are in
/dist/src.

- Enjoy. 

Here fpc poly-sys in action:


 

Fre;D





-
Many thanks ;-)
--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/polYdev-release-1-0-with-fpc-as-superstar-tp5726374.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

Re: [fpc-pascal] with no if assigned() there are bugs

[Graeme Geldenhuys]

On 2016-09-21 14:23, Pierre Free Pascal wrote:
> I assume that your system is a
>   x86_64-linux...

Yup.


>   So if you are using linux OS, -gc option is probably only usable
> starting with today's trunk commits.

Thank you very much.



Regards,
  Graeme

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] with no if assigned() there are bugs

[Pierre Free Pascal]

I assume that your system is a
  x86_64-linux...

  for linux, it seems only 32bit systems are supported,
mainly because there is no stack validation code for 64-bit target...

  The list of supported targets is in: systems_support_checkpointer

For version 3.0.0:
systems.pas:342:   systems_support_checkpointer =
[system_i386_linux,system_powerpc_linux]
systems.pas-343- + [system_i386_win32]
systems.pas-344- + [system_i386_GO32V2]
systems.pas-345- + [system_i386_os2]
systems.pas-346- +
[system_i386_beos,system_i386_haiku]
systems.pas-347- + [system_powerpc_morphos];


  Anyhow, this code seems also broken for i386-linux...

 I just committed two fixes to trunk, 
it is possible to cycle compiler now with -gc option
on both i386 and x86_64 linux.
  As the fix is not cpu specific, I enabled the -gc option
for all linux systems in trunk, but this is untested.

  So if you are using linux OS, -gc option is probably only usable
starting with today's trunk commits.


Pierre

> -Message d'origine-
> De : fpc-pascal-boun...@lists.freepascal.org [mailto:fpc-pascal-
> boun...@lists.freepascal.org] De la part de Graeme Geldenhuys
> Envoyé : mercredi 21 septembre 2016 14:35
> À : fpc-pascal@lists.freepascal.org
> Objet : Re: [fpc-pascal] with no if assigned() there are bugs
> 
> On 2016-09-21 13:27, Pierre Free Pascal wrote:
> >There is also the -gc option:
> >   -gcGenerate checks for pointers
> 
> Interesting, I didn't know about that option.
> 
> Unfortunately under CentOS 6 Linux I get:
> 
> Fatal: Option "-gc" is not, or not yet, supported on the current target
> platform
> 
> 
> Do you know which platforms support the -gc option? Windows, FreeBSD?
> 
> 
> 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
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] with no if assigned() there are bugs

[Graeme Geldenhuys]

On 2016-09-21 13:27, Pierre Free Pascal wrote:
>There is also the -gc option:
>   -gcGenerate checks for pointers

Interesting, I didn't know about that option.

Unfortunately under CentOS 6 Linux I get:

Fatal: Option "-gc" is not, or not yet, supported on the current target
platform


Do you know which platforms support the -gc option? Windows, FreeBSD?


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] with no if assigned() there are bugs

[Pierre Free Pascal]

> -Message d'origine-
> De : fpc-pascal-boun...@lists.freepascal.org [mailto:fpc-pascal-
> boun...@lists.freepascal.org] De la part de Martin
> Envoyé : mercredi 21 septembre 2016 12:38
> À : FPC-Pascal users discussions
> Objet : Re: [fpc-pascal] with no if assigned() there are bugs
> 
> On 21/09/2016 09:05, Mark Morgan Lloyd wrote:
> >
> > Presumably this would be an assertion that something is assigned. A
> > related test is that an object is a specific subtype before using it
> > as such
> >
> >   Assert(PageControl1.ActivePage.Controls[0] is TSynEdit);
> >   syn := TSynEdit(PageControl1.ActivePage.Controls[0]);
> 
> The problem is that even a test like that would NOT catch all cases.
> 
> syn.destroy;
> Assert(syn is TSynEdit);
> 
> In this case, it is very likely that "syn is TSynEdit" still returns
> true. (no assertion thrown)
> 
> Simply because "syn.destroy;" does not wipe the memory clean.
> (depending
> on mem manager)
> 
> Using -gh
> And (optionally) setting the environment HEAPTRC="keepreleased" (that
> is
> for debugging only)
> http://www.freepascal.org/docs-html/rtl/heaptrc/environment.html
> will help.

   There is also the -gc option:
  -gcGenerate checks for pointers

  This is another debugging option, that is not used very often,
so that it might not always work correctly, but it could be worth a try in
your case.

  It probably does not work well if threads are used, but in principle,
it calls checkpointer function before any pointer dereference.
  The exact action of checkpointer depends on the operating system,
the code is also in heaptrc.pp unit.

 In the hope it will be useful,

Pierre Muller
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] with no if assigned() there are bugs

[Mark Morgan Lloyd]

On 21/09/16 11:00, Martin wrote:

On 21/09/2016 09:05, Mark Morgan Lloyd wrote:


Presumably this would be an assertion that something is assigned. A
related test is that an object is a specific subtype before using it
as such

  Assert(PageControl1.ActivePage.Controls[0] is TSynEdit);
  syn := TSynEdit(PageControl1.ActivePage.Controls[0]);


The problem is that even a test like that would NOT catch all cases.

syn.destroy;
Assert(syn is TSynEdit);

In this case, it is very likely that "syn is TSynEdit" still returns
true. (no assertion thrown)


Absolutely. But as you say later, anybody who doesn't use FreeAndNil() 
is asking for trouble.



Simply because "syn.destroy;" does not wipe the memory clean. (depending
on mem manager)

Using -gh
And (optionally) setting the environment HEAPTRC="keepreleased" (that is
for debugging only)
http://www.freepascal.org/docs-html/rtl/heaptrc/environment.html
will help.

On top of that you can use -CR

Also search suspected code for every "destroy" or "free" and, replace
with FreeAndNil(var) if possible.


[From elsewhere a few years ago, somebody's wife looked over his 
shoulder and saw his Delphi code full of Create and Destroy calls. "Bit 
violent isn't it?" she remarked.]


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] with no if assigned() there are bugs

[Martin]

On 21/09/2016 09:05, Mark Morgan Lloyd wrote:


Presumably this would be an assertion that something is assigned. A 
related test is that an object is a specific subtype before using it 
as such


  Assert(PageControl1.ActivePage.Controls[0] is TSynEdit);
  syn := TSynEdit(PageControl1.ActivePage.Controls[0]);


The problem is that even a test like that would NOT catch all cases.

syn.destroy;
Assert(syn is TSynEdit);

In this case, it is very likely that "syn is TSynEdit" still returns 
true. (no assertion thrown)


Simply because "syn.destroy;" does not wipe the memory clean. (depending 
on mem manager)


Using -gh
And (optionally) setting the environment HEAPTRC="keepreleased" (that is 
for debugging only)

http://www.freepascal.org/docs-html/rtl/heaptrc/environment.html
will help.

On top of that you can use -CR

Also search suspected code for every "destroy" or "free" and, replace 
with FreeAndNil(var) if possible.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] with no if assigned() there are bugs

[Mark Morgan Lloyd]

On 21/09/16 06:30, Tomas Hajny wrote:

On Wed, September 21, 2016 07:29, Lars wrote:


Hi,


Hi all, I am wondering what your thoughts are on this
idea: add the ability to do if assigned() on all
objects to prevent bugs, maybe as a compiler feature.

 .
 .

What would be the supposed "else" clause of your "if" statement? I assume
that the original action with the given object should not be ignored
silently, because that would lead to even more difficult debugging of such
bugs. Run-time error? But that is already happening with access violation
too. Or...?


Presumably this would be an assertion that something is assigned. A 
related test is that an object is a specific subtype before using it as such


  Assert(PageControl1.ActivePage.Controls[0] is TSynEdit);
  syn := TSynEdit(PageControl1.ActivePage.Controls[0]);

but I'd suggest that this is as much a refactoring problem as one which 
should be tackled by the compiler.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] with no if assigned() there are bugs

[Tomas Hajny]

On Wed, September 21, 2016 07:29, Lars wrote:


Hi,

> Hi all, I am wondering what your thoughts are on this
> idea: add the ability to do if assigned() on all
> objects to prevent bugs, maybe as a compiler feature.
 .
 .

What would be the supposed "else" clause of your "if" statement? I assume
that the original action with the given object should not be ignored
silently, because that would lead to even more difficult debugging of such
bugs. Run-time error? But that is already happening with access violation
too. Or...?

Tomas


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] with no if assigned() there are bugs

[Michael Van Canneyt]

On Tue, 20 Sep 2016, Lars wrote:


Hi all, I am wondering what your thoughts are on this idea: add the
ability to do if assigned() on all objects to prevent bugs, maybe as a
compiler feature. Before you write me off as just another person
requesting yet another silly feature (it may in fact be that), here is the
problem:

A lot of "other people's code" I deal with, has access violations. When I
try to debug the application code, I waste hours of my time, only to find
out that it was that common bug: a person forgot to check

 if assigned(SomeObject)

before accessing the object properties or fields.  i.e. the access
violation was because of referencing an invalid (non existing) object.

So what if the compiler had an option to check if assigned, before
accessing any object. This would seem to be like a performance hit however
I'm not sure that an If check is that much of a waste of CPU power. It
would be similar to range checking: yes, may be a performance hit, but
increases safety of application.


This would in general be a very bad idea.

If there is no 'If Assigned()', it means the person who programmed it,
assumes the object is always valid at that point. 
If it is not, you should ask yourself why it is not valid, 
and not hide the problem by adding "if Assigned()" automatically.


The -CR command-line option more or less does this, but I am not sure if it
also checks field or property access.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal