valgrind run

[llnl]

valgrind run

[mcneish1]

-DCMAKE_BUILD_TYPE=RelWithDebInfo

[nightlark]

--track_origins and using a build type of Debug (for the -g flag) works on LC to make valgrind report line numbers, but on Travis it doesn't. The versions of valgrind are similar (3.10 on Travis, 3.13 on LC).

[phlptp]

Usually you want the -g flag with -02/1 or something like think. I think usually add -g to the CMAKE_CXX_FLAGS or something like that.

[phlptp]

we should probably run --leak-check=full as well

[nightlark]

CMake's Debug build type adds the flags for generating an executable with debug information based on the compiler -- for gcc it uses "-g"; I started a build using CMAKE_C/XX_FLAGS set to "-g" (and wiped the cache before starting the build), maybe the check for the build type has a mistake. --leak-check=full is the default

[nightlark]

Here's a build log with "-g" using CMAKE_C/XX_FLAGS and --leak-check=full: https://travis-ci.org/LLNL/GridDyn/jobs/403627913
And here's using a build type of Debug to get "-g" and not explicitly setting leak-check: https://travis-ci.org/LLNL/GridDyn/jobs/403376818

The same set of build commands on LC (as the 2nd/before log, with only --track-origins added) results in line numbers being attached to the stack traces printed by valgrind; I can't imagine the difference between those two versions of valgrind are that big, so maybe the standard libraries need to be built with a debug symbols?

I think adding an "OptimizedDebug" build type that has "-g -O2" set might be a useful addition that could also be used for the sanitizers.

[nightlark]

I ran the test again on LC using their oldest copy of valgrind (3.11), and it still shows line numbers. It looks like it shows line numbers when I run it on LC even without the --track-origins flag.

[nightlark]

I think I've been able to replicate the lack of line numbers even when building GridDyn with debug symbols on LC; it looks like only autobuilding the release version of SuiteSparse and/or Sundials prevents line numbers from showing up; an option to autobuild only the debug version of the libraries might be useful to make the line numbers show up, without building unused copies.

[phlptp]

When I have built with the sanitizers/valgrind before I think I always used release build but added -g to the CMAKE_CXX_FLAGS + all the sanitizer flags, instead of building with the DEBUG build. otherwise it was rather slow, especially for some of the sanitizers. Most recommend building with at least -01.

But that isn't a bad idea to add DEBUG only option to the autobuilds

[phlptp]

I think I know how to get that running with the autobuilds, but need to try it out so will be a couple days.

[nightlark]

With BUILD_DEBUG_ONLY I'm having problems with it not finding sunlinsol/sunlinsol_klu.h

[nightlark]

Only IMPORTED_LOCATION_RELEASE is used for getting the location of the KLU library when building Sundials.

It feels like the autobuilds for dependencies should follow the CMAKE_BUILD_TYPE, but then if you change the build type without deleting the autobuild directory, the old dependency won't get imported correctly if the configuration used is based on the build type. And if the system has a copy of KLU installed, that's probably only provided as release or debug builds.

[nightlark]

Although, it looks like Sundials only looks for SuiteSparse libraries without the "d" prefix, so maybe it would make more sense to skip the different build types and just default to a release build with debug info for Sundials/SuiteSparse, unless doing a build for public release; that would avoid the added complexity of using different install directories for libraries with different build types (otherwise release, minsizerel, and relwithdebinfo build types will overwrite libraries built by each other).

[phlptp]

That might work on Linux, but That doesn't work as well on Windows, you end up with different command options and never ending warnings. I also am a little annoyed at the sundials findKLU, it seems very fragile. I have run into any number of issues with it, but they haven't fixed it yet. I also have thought about making sundials a subproject so it would get built when the rest of the project is built. That would solve some of the issues with the changing options that affect sundials in the cmake configure. It just tends to make a mess of the targets for GridDyn.

Maybe we should make separate build commands in the autobuild for visual studio vs the other ones. Visual studio would build DEBUG and one of RELEASE/RelwithDebInfo/minSizeRel and everything else would just build the CMAKE_BUILD_TYPE.

The interesting thing about sundials and KLU is that it does a build to test KLU. I have tried to find a way to bypass this but haven't been successful yet.

[nightlark]

Finally figured out why I was getting different results on Travis and LC.