Giulio Bernardi wrote

So, how can I compile a "debug version" of rtl so that I can use it when debugging the program?

Download the source of the rtl from
http://www.freepascal.org/develop.html#sources

Go in the rtl directory and type

make OPT=-g

Next, when compiling your program, add "-FuPath_to_newly_compiled_RTL" to the command line options of the compiler.

Jonas

Hi.
I'm writing a sort of "compiler" for a language similar to php (so it is not a compiler since
it doesn't produce any object code, it only checks syntax and so on). I use delphi 6 on
win32, and freepascal 1.9.x on Linux/i386 and Mac OS X. Sometimes I compile it with
fpc under win32 too.
It works great when compiled with fpc 1.9.0, but I have strange problems when using
fpc 1.9.2 and 1.9.3: it compiles correctly, but I have a lot of acces violations when running
the program, and the program behaves differently when compiled with or without range checking.
This program makes an heavy use of dynamic arrays and recursion. I tried to debug it using gdb, and I noticed a bad behavoir in setlength function:
I have a method that adds things to a dynamic array, using setlength to increase its size dinamically.
When the array is empty, everything is okay (array grows to 1, and data is set). When I add another
item, array grows to 2, but contents of the first element (element 0) are corrupted: when I try to
access it, sometimes i receive garbage data, sometimes I have an access violation.
I have this same problem under win32, linux/i386 and MacOS X.

I wasn't able to reproduce the bug in a simple program, so I would like to step into setlength to see
what does happen.

So, how can I compile a "debug version" of rtl so that I can use it when debugging the program?
Thanx,
Giulio

So, how can I compile a "debug version" of rtl so that I can use it when debugging the program?

'make OPT=-gl' will do the trick.

Joost van der Sluis.

Giulio and All,

if you really want to do that and fix the problem, I also will be very happy, so maybe that will be an extra motivation for you :)

For two years I have been trying FPC on my projects, that use dynarrays heavily. There were always problems, first year I was patiently reporting each new problem, but when I saw that they never go away, or go away and then return, or go away in few month to let me see next problem, I decided that this way the dynarrays in FPC will only work after 10 years, so I gave up. SetLength for dynarrays and openarrays, was always corrupting memory. It was fixed many times, and still does that again. And yes, you cannot often creat simple programs to bug report them. It probably has to do something with functions calling, releasing memory at the end of function, or something of that sort.

I guess the problem with dynarrays and openarrays (also as with overloaded functions wich are also very buggy for a long time) is the fact that FPC core team are old stylish programmers, and do not use these modern features themselves. Thus these features are "for users" and are not so solid. Instead you guys use pointers to arrays, getmem and other manually controlled "dynamic arrays" and other structures, but not actual pascal dynarrays. Same with openarrays and overloaded functions. I guess what you could do, strictly IMHO, is start using these features across the compiler code, so all your regression tests and other tests will constantly keep the dynarray features healthy.

Thank you,
Yakov Sudeikin

This could be one dangling pointer that is messing up your heap.

Please keep to the facts, and don't spread unnecessary rumours.

Overloaded functions were present before Delphi had them, so I would be very surprised if this was the case.

That they don't behave as in Delphi is another matter. We implemented it _first_, and can't be blamed if Delphi does it differently.

As for 'old stylish': I am employed as a Delphi programmer since many years, and I've used dynamic arrays with care. In general, it's not a good data type to use; One is often better off with TList or even TObjectList.

I guess what you could do, strictly IMHO, is start using these features across the compiler code, so all your regression tests and other tests will constantly keep the dynarray features healthy.

This would actually be a very bad idea, because the use of dynamic arrays has a performance penalty (sometimes really serious ones), which we want to avoid in the compiler. Also, we feel it is better to do some things manually for performance reasons.

This is also why Ansistrings are not used in the compiler. They are convenient, but have a performance penalty if used carelessly.

beside these reasons, I think that a dynamic array is not a suitable structure for the compiler, where linked lists and dictionaries are more natural and needed.

Michael.

Is there a Unit Test for Dynamic Arrays? If not, perhaps the original poster could help to contribute one. I use Dynamic Arrays heavily in Delphi and I'm just getting into FPC and Lazarus, and I'm very interesting in having a unit test for FPC Dynamic arrays to accomplish the following:

(1) Do all possible operations on Dynamic arrays, report total heap size before they are created, and after they are freed. (P.S. Is a debug-heap an option in FPC somewhere?). Use dynamic arrays in record, class, and local function scope, check recursion, param and var param usage, etc etc. If FPC has range checking {$R+} like Delphi, perhaps tests for this can be created too.

(2) Be compilable via FPC and Delphi, and work identically on both, {$ifdef} where necessary.

(3) Generally serve to either to locate any real problem (if one really exists), or to ensure that no accidental breakage can slip by undetected. If I have some time, I will write such a beastie as an exercise. If Yakov you have any code that exhibits the broken behavior, or you can contribute anything to this, it would be great. Later, I want to figure out how to implement Packages in FPC, but I figure I may as well pick a baby-size idea first. This one sounds like it's easy.

Regards,

Warren Postma
Delphi Guy / FPC newbie.

It is also not possible to use new features in the compiler. The compiler needs to be able to be compiled with 1.0.x for bootstrapping.

Modern features like dynarrays and variants are for quick GUI/database applications perfect, but you don't want to use that kind of things in server daemons and programs that need to be run for a long time without downtime, because you don't have full control over things that happend.

At my job there is a rule in the coding standards that you shouldn't use malloc/getenvironmentvariable during the main processing, it is only allowed during startup because it is to slow. And for malloc there is the extra risk of memory leaks.

For the compiler compile speed is important (ppl want to compare it with Delphi). Things like dynamic arrays and ansistrings are simply too slow, because they require extra overhead for exception handling.

Peter

We have a testsuite available. See the fpc/tests/ directory in cvs or fpc.zip. This testsuite contains a lot of basic tests for the codegenerator and all reported bugs that are reproducable in non-interactive test programs.

The testsuite is run daily for Linux-i386 and the results can be viewed online at http://www.freepascal.org/cgi-bin/testsuite.cgi

Peter

It is also not possible to use new features in the compiler. The compiler needs to be able to be compiled with 1.0.x for bootstrapping.

This may be a dumb question but, can you explain what you mean by this, and why this is not possible?

When building a new compiler you always start with the latest released compiler (1.0.10). This is required to have a stable and reproducable build environment.