Re: [Plplot-devel] Possible fix for the test_ada project on Cygwin (NO LONGER RELEVANT)

[Alan W. I. <ir...@be...>]

On 2017-11-07 12:35-0000 Arjen Markus wrote:

> Hi Alan,

> I got an odd error while running the comprehensive test script for
Ada - see the attached tarball. The good news is that it was a crash
in running the program, not an interruption of the build process.

Hi Arjen:

To clean up some preliminary stuff, please don't set GNAT_LIB unless
absolutely necessary.  Specifying that variable is a workaround that
bypasses all testing of the find_library command (see
<https://cmake.org/cmake/help/v3.10/command/find_library.html> for why
that is so.  For example, it completely bypasses the changed
find_library command in my patch.  Instead, I would prefer you to set
the environment variable CMAKE_LIBRARY_PATH (if necessary) to the
directory location where the gnat import library can be found.  That
method then tests whether find_library works properly (which is part
of the point of these tests).

Furthermore, the run-time error you found was for the shared case so
please follow up by testing whether that also occurs for the static case using

cmake/test_ada/scripts/comprehensive_test.sh --do_shared no

(that "--do_shared no" option skips over the shared part of the test
as documented if you run cmake/test_ada/scripts/comprehensive_test.sh
--help).

Moving on to the run-time error you found for the shared case, i.e.,

raised PROGRAM_ERROR : EXCEPTION_ACCESS_VIOLATION

, that issue was just raised for the installed examples case
and not the build-tree case which is an interesting result.

So from your report tarball I looked carefully at how the two
different cases were built, i.e.,

# Build tree
/usr/bin/gnatmake.exe  -Wl,--enable-auto-import "-aI/cygdrive/d/plplot-svn/plplot-git/cmake/test_ada/src_executable" "-aI/cygdrive/d/plplot-svn/plplot-git/cmake/test_ada/src_lib" "-aL/cygdrive/d/plplot-svn/comprehensive_test_ada_disposeable/shared/noninteractive/build_tree/src_lib/CMakeFiles/hello_1.dir" hello.adb -cargs  -largs ../dll/libhello.dll.a 
# Build tree for the installed example
/usr/bin/gnatmake.exe  -Wl,--enable-auto-import "-aI/cygdrive/d/plplot-svn/comprehensive_test_ada_disposeable/shared/noninteractive/install_tree/share/test_ada/examples/ada" "-aI/cygdrive/d/plplot-svn/comprehensive_test_ada_disposeable/shared/noninteractive/install_tree/share/ada/adainclude/test_ada" "-aL/cygdrive/d/plplot-svn/comprehensive_test_ada_disposeable/shared/noninteractive/install_tree/lib/ada/adalib/test_ada" hello.adb -cargs  -largs /cygdrive/d/plplot-svn/comprehensive_test_ada_disposeable/shared/noninteractive/install_tree/lib/libhello.dll.a

My experience is gnatmake is extraordinarily picky about its builds
and will error out if the slightest thing is wrong.  But all was well
in that regard with your two builds.  Furthermore, visual inspection
of the two separate commands above indicates the two different
versions refer respectively to build-tree and installed examples build
tree locations (as expected).  In addition, Ada libraries are really
straightforward to build and install (build the objects from *.adb
source with no special gcc options other than -fPIC, collect the
generated object files in a library and keep track of the
corresponding Ada *.adb source files and generated *.ali files and
install the library, and its corresponding *.ada and *.ali files.) If
that installation were incomplete in the slightest way, the above
second gnatmake command would have errored out. So I really think all
is well with the install.

Thus, the only thing I can think of to follow up with this error is
the above PROGRAM_ERROR appears to be referring to a memory management
issue.  Often those are silent errors (especially on Windows) so by
accident the given memory management issue might be silent for the
build tree but not for the installed examples build tree.  So I looked
for that sort of issue here (Debian Jessie) after a run of

cmake/test_ada/scripts/comprehensive_test.sh

as follows:

# change to comprehensive test prefix directory
software@raven> cd ../comprehensive_test_ada_disposeable
# valgrind test hello executables in both the build and installed
# examples build directories.
software@raven> valgrind shared/noninteractive/build_tree/src_executable/hello
==26389== Memcheck, a memory error detector
==26389== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==26389== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==26389== Command: shared/noninteractive/build_tree/src_executable/hello
==26389== 
==26389== 
==26389== HEAP SUMMARY:
==26389==     in use at exit: 0 bytes in 0 blocks
==26389==   total heap usage: 4 allocs, 4 frees, 740 bytes allocated
==26389== 
==26389== All heap blocks were freed -- no leaks are possible
==26389== 
==26389== For counts of detected and suppressed errors, rerun with: -v
==26389== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

software@raven> valgrind shared/noninteractive/install_build_tree/ada/hello
==26390== Memcheck, a memory error detector
==26390== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==26390== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==26390== Command: shared/noninteractive/install_build_tree/ada/hello
==26390== 
==26390== 
==26390== HEAP SUMMARY:
==26390==     in use at exit: 0 bytes in 0 blocks
==26390==   total heap usage: 4 allocs, 4 frees, 740 bytes allocated
==26390== 
==26390== All heap blocks were freed -- no leaks are possible
==26390== 
==26390== For counts of detected and suppressed errors, rerun with: -v
==26390== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

As you can see, there are perfect memory management results on Linux
for both these cases.

Therefore, since test_ada is so simple, I am beginning to lean toward
an explanation that there is something fundamentally wrong with the
Ada component of the gcc tool chain on Cygwin.  To test that
hypothesis further is there an equivalent to valgrind (see
<https://stackoverflow.com/questions/413477/is-there-a-good-valgrind-substitute-for-windows>
for some ideas) that you could run?  And if you do find a memory
management issue on Cygwin that way, could you also try the same tool
on the simplest shared gnatmake example I asked you to build the other
day?  That would be the first step in preparing a bug report to the
Cygwin mailing list concerning the Ada component of the gcc tool chain
based not on test_ada but on that even simpler shared gnatmake
example.

Alan

__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________