NDEBUG and member variables about cppad

[bradbell]

Thanks for the feedback. I am currently busy with work on a different package. I expect to get back to CppAD in the middle of May and will work on this then.

[bradbell]

I have begun work on this bug in the directory
https://github.com/coin-or/CppAD/tree/master/test_more/debug_rel

The idea is that the debug.cpp file (release.cpp file) will be compiler for debugging (release) that the debug_rel.cpp program use both. I will then create tests cases that fail and then fix them one at a time; i.e., a test driven development approach.

[bradbell]

The with NDEBUG and without NDEBUG versions of CppAD are not compatible. They assume all the rest of CppAD is compiled the same way. For example, the CppAD memory allocator does some tracking between function calls when NDEBUG is defined and it needs to be done for all allocations for it to work. What I do is to have two separate build and install directories.
build.debug
build.release
prefix/package.debug
prefix/package.release

Then I use a soft link from
build -> build.debug
prefix/package -> prefix/packabge.debug
to get the debug version.

Would this work for you ?

[joaoleal]

I create a Debian package for the library and then install it in the system.
It is not common to have multiple versions of the same library for different compilation flags installed in Debian/Ubuntu.
Nonetheless, I will try to create different versions of the library in the Debian package and then load the correct one for the executable using CMake.

Thank you!

[bradbell]

Perhaps I should can put a separate flag on the things that make the Debug and Release version incompatible. I have put it on the CppAD wish list; see
f7f04b6

Thanks.

[joaoleal]

Thank you!

Note: I just realized that I will have to create different library versions for extra 4/5 libraries that also depend on that library :(

[joaoleal]

I've looked in CppAD sources and it appears that the only reason why ADFun changes size/structure is due to the following lines in class player:

# ifndef NDEBUG
	/// Flag indicating that a special function must be called before next
	bool      special_before_next_;
# endif

I've removed the # ifndef NDEBUG and #endif and left the member variable be always defined (even if it is not used) and I am able to generate my models but it then fails during destruction.

[bradbell]

I am busy right now with other things, but I can help a little, if you want to try and do this.

I suggest adding the flage CPPAD_EXTRA_DEBUG to the file
cppad/configure.hpp.in
Do not worry about setting it using cmake (I can do that later).

Next I would do a
git grep special_before_next_
and change all the NDEBUG guards to use CPPAD_EXTRA_DEBUG as a guard.

I think you will also have to make this change for the NDEBUG that appear in
cppad/utility/thread_alloc.hpp

[joaoleal]

I've compared both versions of my library with and without NDEBUG using https://lvc.github.io/abi-compliance-checker/ and found that there are many issues...
I cannot identify the root cause for many of the reported differences.
For instance, it says:

namespace CppAD
[−] old_atomic<cg::CG<double> >::forward ( size_t p, size_t q, vector<bool>const& vx, vector<bool>& vy, vector<cg::CG<double> >const& tx, vector<cg::CG<double> >& ty )  1  
	Change	Effect
1	The parameter ty became passed at the different offset on the stack (0 instead of -48).	Violation of the calling convention. This may result in crash or incorrect behavior of applications.

I think I might be safer to go the way of making different packages for the library.

[bradbell]

Thanks for trying. It has helped me to see the problems you have run into. I need to come up with a way to determine which NDEBUG statements are causing the difficulty.

[futuretristan]

I just came across the same problem and would be interested in a solution as well.

I'm working on a library that internally uses CppAD and that I share with other people. If someone just wants to use the library and not modify it, that person will most likely build it with 'Release' type setting in CMake. Unfortunately, CMake then automatically sets the -DNDEBUG compiler flag for library compilation.

If the users executable linking to the library is then compiled as a Debug project, errors are thrown when destructors of the library are called and the user has no idea what this is :)

[bradbell]

I have found an interesting article on this for gcc; see
Link- and run-time coexistence of release- and debug-mode components
on
https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode_design.html#methods.coexistence.link

[bradbell]

I am working on the debug_rel branch; see
https://github.com/coin-or/CppAD/commits/debug_rel

[bradbell]

I have added random selection of debug versus release to many of the cppad tests and they all seem to work (in the debug_rel branch). Please try this version and see if you have any problems mixing debug and release. Add the following flag, when you compile your tests:
-DCPPAD_DEBUG_AND_RELEASE
I will continue trying to find a case that fails. If you and I do not find any problems, I plan to merge debug_rel into the master branch.

[bradbell]

If I use the clang compiler, and set random_choice_0123 to 0, make check_example_general is failing. I am tracking this down.

There was a problem with the test
example/general/compare_change.cpp
when mixing debug and release. This was fixed in
4876d14

[futuretristan]

When I type in the following commands

git clone https://github.com/coin-or/CppAD.git
cd CppAD
git checkout debug_rel
mkdir build && cd build
cmake ..

then in the end Cmake reports that several tests are available

-- make check_example_optimize: available
-- make check_example_print_for: available
-- make check_example_sparse: available
-- make check_example_utility: available
-- make check_example: available
-- make check_introduction: available
-- make check_det_by_minor_c: available
-- make check_det_by_minor_cpp: available
-- make check_test_more_compare_c: available
-- make check_test_more_debug_rel: available
-- make check_test_more_general: available
-- make check_test_more: available
-- make check_speed_cppad: available
-- make check_speed_double: available
-- make check_speed_example: available
-- make check_speed: available
-- make check: avialable

However, when I try and run a test with make check, then the output is

Scanning dependencies of target speed_example
[  0%] Building CXX object speed/example/CMakeFiles/speed_example.dir/example.cpp.o
clang: error: no such file or directory: 'NOTFOUND'
make[3]: *** [speed/example/CMakeFiles/speed_example.dir/example.cpp.o] Error 1
make[2]: *** [speed/example/CMakeFiles/speed_example.dir/all] Error 2
make[1]: *** [CMakeFiles/check.dir/rule] Error 2
make: *** [check] Error 2

How do you run the tests and where exactly do you have to specify the -DCPPAD_DEBUG_AND_RELEASE flag? If I do cmake -DCPPAD_DEBUG_AND_RELEASE .. in my build directory, the output is

Parse error in command line argument: -DCPPAD_DEBUG_AND_RELEASE
Should be: VAR:type=value
CMake Error: No cmake script provided.
CMake Error: Problem processing arguments. Aborting.

[bradbell]

I merged the debug_rel branch into the master yesterday, so you can now use the master branch for this purpose. Coin should have built the documentation (from the master branch) this morning, but the Coin web site is down, so i will point you to the source code for the documentation.

See $subhead CPPAD_DEBUG_AND_RELEASE$$ in
https://github.com/coin-or/CppAD/blob/master/omh/preprocessor.omh

See $head cppad_debug_which$$ and $subhead debug and release$$ in
https://github.com/coin-or/CppAD/blob/master/omh/install/cmake.omh

I also suggest using verbose make files to see the compilation mode being use;
see $head cmake_verbose_makefile$$ in
https://github.com/coin-or/CppAD/blob/master/omh/install/cmake.omh

[bradbell]

My testing (with the current master branch) has not indicated any problems mixing debug and release when
-DCPPAD_DEDBUG_AND_RELEASE
is specified on the compile command line. If you have a case that is not working, please re-open this bug.

[joaoleal]

Hello Brad, Thank you for the update! 2017-06-04 13:17 GMT+01:00 Brad Bell <[email protected]>:

…

My testing (with the current master branch) has not indicated any problems mixing debug and release when -DCPPAD_DEDBUG_AND_RELEASE is specified on the compile command line. If you have a case that is not working, please re-open this bug. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#21 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAfTYYkL0ZS35lj0tn8pVfmQ0l8TmrcIks5sAqBjgaJpZM4NAjJc> .

[bradbell]

If you would like to run the CppAD tests of this feature; see debug_odd and debug_even under the heading debug_which on
https://www.coin-or.org/CppAD/Doc/cmake.htm#cppad_debug_which