So I did try building it manually with the trunk, and for some reason it
failed on that as well, even though it didn't appear in the test suite
as a failure. Definitely confusing, but it tells me that the failure
might not be due to my changes. I'll keep an eye out though to see if
anything crops up.
Gareth aka. Kit
On 03/05/2019 17:34, J. Gareth Moreton wrote:
Thanks Jonas.
On 03/05/2019 17:28, Jonas Maebe wrote:
On 03/05/2019 17:48, J. Gareth Moreton wrote:
So I was doing some refactoring work, and ran the test suites to see
if nothing broke. It turned out that I got a single failure in
test/cg/variants/tnofalvarol.pp - seems a little odd because my
changes weren't meant to change the output of binary files in any
way. But looking at the test in question, all I get is a wall of
$include definitions. Running it in Lazarus isn't too helpful either
because the stack trace doesn't reveal where the erroneous line is,
only that seven levels down, an error occurs in "destructor
tdynarrayiter.done;" in the variants unit, but doesn't know which
line exactly - exception EVariantError with message: "Invalid
variant type cast".
"destructor tdynarrayiter.done;" is part of
packages/rtl-objpas/src/inc/variants.pp. You don't get more
information because all units from the packages directory are
compiled with optimizations and without debug information by default.
You will have to compile that unit with debug information (you can
add OPT="-O- -gw" to the make command when building all of FPC to get
everything built without optimizations and with debug information).
I suppose what I'm trying to get at is that this test is not very
self-contained and is very hard to debug if it happens to fail, and
I would consider rewriting or replacing it.
The files it includes have been automatically generated,
automatically tested against Kylix, and then
a) if the program compiled with Kylix, it was run to see which
overload Kylix picked and whether it generated an exception, and a
"halt(1)" was (also automatically) placed in the other paths. All
successfully executing tests are included in tnofalvarol.pp to make
the test go faster (compiling and running one program with 100
include files is much faster than compiling 100 separate files)
b) if the program did not compile with Kylix, it was kept as a
separate program (since if you include two failing programs in a
single program and it fails to compile, we can't test whether both
errors were detected).
You can still compile the individual include files of the test as
separate programs to test and debug them separately. Once you compile
the variants unit with debug information, you should be able to
easily see which individual test is crashing based on the backtrace.
Jonas
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel