c++11 oddness

[Samuel Flores]

Guys,

Does simbody need to be compiled with the -std=c++11 flag?

Molmodel uses this flag, and it appears that using it plus some odd memory leaks. Actually I had to use -std=c++0x for some reason, rather than -std=c++11, even though I'm using gcc 5.1.0.

At any rate, I would think it would be necessary to also compile simbody using standard 11. However there is no CMake variable (at least not through the interactive interface) available to turn that on. Is this an issue? I ask because I'm having a second memory leak which is refractory to my hammering and anguish.

Sam

[Michael Sherman]

Hi, Sam. Simbody's master branch requires c++11 and there is no other option. The Simbody 3.5 branch (or release) will build either way (via a CMake variable), with the default being c++11. (See README.md for more info.)

For Simbody+Molmodel you definitely do have to use the same c++ standard level for both or expect seg faults!

If you are looking for a good stable release of Simbody to use, the latest release is Simbody 3.5.3 (from the 3.5 branch), with the release posted here: https://github.com/simbody/simbody/releases, with a source zip.

Regards,
Sherm

[Michael Sherman]

P.S. Molmodel really ought to be moved to GitHub. Got any experts there who might want to do that?

[Samuel Flores]

For some reason my c++ does not recognize the -std=c++11 flag. I hacked molmodel and simbody to both take -std=c++0x , which hopefully is good enough.

I don't have anyone writing code at the moment, unfortunately. I have been thinking of doing it myself, at least for MMB. Is this an easy thing to do?

Sam

[Michael Sherman]

I'm surprised by your compiler's failure to recognize -std=c++11; both gcc and clang have for some time. Are you running very old versions? Maybe time for an update?

Moving to GitHub isn't *very* hard, but there is a little black art to it for preserving history and authorship. Luckily it can be attempted and then thrown away until you get it right -- it took us quite a few tries to get Simbody and OpenSim GitHub repos that we liked.

Sherm

[Samuel Flores]

Turns out my build was effectively looking at an older version of gcc. I'm able to build to c++11 fine now. I was able to get past all the compile and link errors.

However I am now having runtime errors which are driving me nuts. On OSX (10.9.5) I am able to run MMB in Release mode with no problems, which is a relief. However in Debug mode I get this runtime error:

../src/BiopolymerClass.cpp:3434
Assertion failed: (i>=0 || i==SimTK::InvalidIndex), function MobilizedBodyIndex, file /Users/Sam/github/simbody-Simbody-3.5.1/Simbody/./include/simbody/internal/common.h, line 95.

BiopolymerClass.cpp has:

3434 std::cout<<__FILE__<<":"<<__LINE__<<std::endl;
3435 SimbodyMatterSubsystem matter(system);
3436 std::cout<<__FILE__<<":"<<__LINE__<<std::endl;
3437 GeneralForceSubsystem forces(system);

gdb won't step into the simbody code, or at least I haven't figured out how to make it do so.

On Linux (SL 6.6 Carbon) on Release I get a runtime error after going one line further down in BiopolymerClass.cpp:


/home/samuelf/svn/RNAToolbox/trunk/src/BiopolymerClass.cpp:3434
/home/samuelf/svn/RNAToolbox/trunk/src/BiopolymerClass.cpp:3436
*** glibc detected *** ./MMB: munmap_chunk(): invalid pointer: 0x0000000001fb9260 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3000875e66]
/home/samuelf/SimTK/lib/libSimTKmolmodel.so(_ZN5SimTK26DuMMForceFieldSubsystemRepC1Ev+0x7e)[0x2b6690330aee]
/home/samuelf/SimTK/lib/libSimTKmolmodel.so(_ZN5SimTK23DuMMForceFieldSubsystemC1ERNS_24MolecularMechanicsSystemE+0x26)[0x2b6690329b16]
/home/samuelf/svn/RNAToolbox/trunk/build/libMMBlib.so(_ZN24BiopolymerClassContainer20loadSequencesFromPdbEN5SimTK6StringEb+0x2d7)[0x2b668ff31e17]
/home/samuelf/svn/RNAToolbox/trunk/build/libMMBlib.so(_ZN15ParameterReader20loadSequencesFromPdbEPKc+0x231)[0x2b668ffcdfd1]
/home/samuelf/svn/RNAToolbox/trunk/build/libMMBlib.so(_ZN15ParameterReader26parameterStringInterpreterERK20ParameterStringClassibbb+0x3d1dc)[0x2b66900123dc]
/home/samuelf/svn/RNAToolbox/trunk/build/libMMBlib.so(_ZN15ParameterReader22initializeFromFileOnlyEPKc+0x1a8e)[0x2b669001688e]
./MMB(main+0xd3c)[0x4095bc]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x300081ed5d]
./MMB[0x403d89]

On Linux, but now in Debug mode, I am able to get almost all the way to the very end before getting a double free error. It's not a functional issue, because at this point the calculation is completed, but nonetheless indicates a problem. I imagine this error message won't be very informative to you but am appending anyway:

/home/samuelf/svn/RNAToolbox/trunk/src/Repel.cpp:927 Stage 2 completed successfully!
/home/samuelf/svn/RNAToolbox/trunk/src/RNABuilder.cpp:231
*** glibc detected *** ./MMB_Debug: double free or corruption (fasttop): 0x0000000001a34120 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3000875e66]
./MMB_Debug(_ZN9__gnu_cxx13new_allocatorIdE10deallocateEPdm+0x20)[0x43305c]
./MMB_Debug(_ZNSt16allocator_traitsISaIdEE10deallocateERS0_Pdm+0x2b)[0x43193f]
./MMB_Debug(_ZNSt12_Vector_baseIdSaIdEE13_M_deallocateEPdm+0x32)[0x4300b8]
./MMB_Debug(_ZNSt12_Vector_baseIdSaIdEED2Ev+0x41)[0x42e2d5]
./MMB_Debug(_ZNSt6vectorIdSaIdEED1Ev+0x41)[0x4359e3]
/lib64/libc.so.6(__cxa_finalize+0x9d)[0x3000835ebd]
/home/samuelf/svn/RNAToolbox/trunk/build/libMMBlib_d.so(+0x1b1a96)[0x2b40c9c99a96]
======= Memory map: ========

I have been working on this for quite a while now. Do you have any idea what I should try now? I am having trouble rolling back to a trouble free prior build, though I can try to dig up some dormant laptops that might be an OK place to restart from.

Sam

[Michael Sherman]

Hi, Sam. This is hard to analyze from afar, but it looks to me that you might not have up to date source code to match your executable. The assertion failure indicates and illegal MobilizedBodyIndex, but the line number you presented doesn't have any access to MobilizedBodyIndex. It could be made more confusing by the fact that the actual assertion is generated by a macro in Simbody's common.h. So presumably that's not where the error actually occurred. If you haven't already, you could try cleaning out everything and rebuilding from scratch to make certain that the source and binary match.

The double deletion looks like something else and could indicate a real heap-trashing problem. Especially when something fails in Release but runs in Debug, some kind of random memory damage is likely -- memory layout and usage patters are different in Release and Debug so you can get "lucky" and have something work that really shouldn't.

Another thought is that there could still be some compiler flag mismatches. While rebuilding from scratch, be sure that every individual component is build with the same -std=c++11 flag. If anything sneaks in using a different standard you are likely to get bizarre behavior.

I would definitely try to find the most stable compilation environment you have and work through this in Debug, verifying that you are getting reasonable behavior out of the debugger (like it should show stack traces that give the correct line numbers!).

Regards and good luck,
Sherm

[Samuel Flores]

Hi Sherm,

It is turning out to be a real saga to compile to the c++11 standard. The existing simbody and molmodel can build without compile or link errors. However certain operations which I took for granted before, are now stubbornly problematic. Right now I am struggling with the following. I built a minimal program that uses molmodel and produces a stubborn assignment operator error.

temp.cpp contains:

#include "BiopolymerClass.h"
using namespace SimTK;

void BiopolymerClass::setResidueIDsAndInsertionCodesFromBiopolymer(const Biopolymer & inputBiopolymer, bool endCaps = 0 ) {
ResidueInfo myResidueInfo = myBiopolymer.updResidue(ResidueInfo::Index( 0 ));
//ResidueInfo myResidueInfo = myBiopolymer.updResidue(ResidueInfo::Index( 0 ));
myResidueInfo = myBiopolymer.getResidue(ResidueInfo::Index( 0 ));
};

I compile as follows:

/usr/bin/c++ -c temp.cpp -I /usr/local/SimTK/include/simbody/ -I /usr/local/SimTK/include/ -I ../include -I /usr/local/openmm/include/ -I /usr/local/openmm/include/openmm/reference/ -std=c++11 -mmacosx-version-min=10.10

I believe my c++ is up to date:

samuel-floress-macbook-pro-3:build Sam$ /usr/bin/c++ --version
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.4.0
Thread model: posix

As you can see I am now on OSX 10.10 (I upgraded just to see if that would help matters). Someone got rid of this issue by building to a late enough OSX release, but it of course that didn't do it for me.

At any rate, the result is I get a "no viable overloaded '=' " error upon compilation. It is appended with excess verbosity below.

I thought (hmm) .. there is no assignment operator explicitly defined for ResidueInfo. Why not make one in Compound.h? So I made one:

ResidueInfo operator=(const ResidueInfo & inResidueInfo) {
(*this).index = inResidueInfo.index;
(*this).nameInCompound = inResidueInfo.nameInCompound;
(*this).pdbResidueName = inResidueInfo.pdbResidueName;
(*this).oneLetterCode = inResidueInfo.oneLetterCode;
(*this).synonyms = inResidueInfo.synonyms;
(*this).pdbResidueNumber = inResidueInfo.pdbResidueNumber;
(*this).pdbInsertionCode = inResidueInfo.pdbInsertionCode;
(*this).atoms = inResidueInfo.atoms;
(*this).atomIdsByName = inResidueInfo.atomIdsByName;
return *this;
}

It just copies member by member, so seems no different from the default assignment operator. In any case, whereas molmodel previously compiled fine, with this definition I get the "no viable overloaded '=' " error while compiling molmodel.

In short, I can't find a way around this assignment operator issue. How should I go about copying ResidueInfo? I suspect the same issue affects other classes, but for now I would be happy to solve the problem just for ResidueInfo.

Many thanks in advance,

Sam


In file included from temp.cpp:11:
In file included from ../include/BiopolymerClass.h:18:
In file included from ../include/Mutation.h:4:
In file included from ../include/Utils.h:22:
In file included from /usr/local/SimTK/include/SimTKmolmodel.h:51:
In file included from /usr/local/SimTK/include/molmodel/internal/AtomSubsystem.h:6:
In file included from /usr/local/SimTK/include/molmodel/internal/VoxelHash.h:11:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/ext/hash_map:212:5: warning: Use of
the header <ext/hash_map> is deprecated. Migrate to <unordered_map> [-W#warnings]
# warning Use of the header <ext/hash_map> is deprecated. Migrate to <unordered_map>
^
In file included from temp.cpp:11:
In file included from ../include/BiopolymerClass.h:18:
In file included from ../include/Mutation.h:4:
../include/Utils.h:513:9: warning: control may reach end of non-void function [-Wreturn-type]
}
^
../include/Utils.h:533:9: warning: control may reach end of non-void function [-Wreturn-type]
}
^
In file included from temp.cpp:11:
In file included from ../include/BiopolymerClass.h:18:
In file included from ../include/Mutation.h:4:
In file included from ../include/Utils.h:16:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/fstream:169:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/ostream:131:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/ios:216:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__locale:15:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/string:439:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/algorithm:627:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/utility:294:15: error: no viable
overloaded '='
first = __p.first;
~~~~~ ^ ~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/map:610:15: note: in instantiation
of member function 'std::__1::pair<const SimTK::String, SimTK::ResidueInfo::AtomIndex>::operator=' requested here
{__nc = __v.__cc; return *this;}
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__tree:1263:35: note: in
instantiation of member function 'std::__1::__value_type<const SimTK::String, SimTK::ResidueInfo::AtomIndex>::operator=' requested
here
__cache->__value_ = *__first;
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__tree:1204:9: note: in
instantiation of function template specialization 'std::__1::__tree<std::__1::__value_type<const SimTK::String,
SimTK::ResidueInfo::AtomIndex>, std::__1::__map_value_compare<const SimTK::String, std::__1::__value_type<const SimTK::String,
SimTK::ResidueInfo::AtomIndex>, std::__1::less<const SimTK::String>, true>, std::__1::allocator<std::__1::__value_type<const
SimTK::String, SimTK::ResidueInfo::AtomIndex> > >::__assign_multi<std::__1::__tree_const_iterator<std::__1::__value_type<const
SimTK::String, SimTK::ResidueInfo::AtomIndex>, std::__1::__tree_node<std::__1::__value_type<const SimTK::String,
SimTK::ResidueInfo::AtomIndex>, void *> *, long> >' requested here
__assign_multi(__t.begin(), __t.end());
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/map:892:21: note: in instantiation
of member function 'std::__1::__tree<std::__1::__value_type<const SimTK::String, SimTK::ResidueInfo::AtomIndex>,
std::__1::__map_value_compare<const SimTK::String, std::__1::__value_type<const SimTK::String, SimTK::ResidueInfo::AtomIndex>,
std::__1::less<const SimTK::String>, true>, std::__1::allocator<std::__1::__value_type<const SimTK::String,
SimTK::ResidueInfo::AtomIndex> > >::operator=' requested here
__tree_ = __m.__tree_;
^
/usr/local/SimTK/include/molmodel/internal/Compound.h:1748:7: note: in instantiation of member function 'std::__1::map<const SimTK::String,
SimTK::ResidueInfo::AtomIndex, std::__1::less<const SimTK::String>, std::__1::allocator<std::__1::pair<const SimTK::String,
SimTK::ResidueInfo::AtomIndex> > >::operator=' requested here
class ResidueInfo {
^
/usr/local/SimTK/include/simbody/SimTKcommon/internal/String.h:62:7: note: candidate function (the implicit copy assignment operator) not
viable: 'this' argument has type 'const SimTK::String', but method is not marked const
class String : public std::string {
^
/usr/local/SimTK/include/simbody/SimTKcommon/internal/String.h:62:7: note: candidate function (the implicit move assignment operator) not
viable: 'this' argument has type 'const SimTK::String', but method is not marked const
class String : public std::string {
^
3 warnings and 1 error generated.
samuel-floress-macbook-pro-3:build Sam$

[Samuel Flores]

I managed to get rid of the "no viable overloaded '=' " error by not copying ResidueInfo objects. I see that these are declared as references, so maybe they should not be copied in principle?

In any case now compilation and linking proceed without any error messages. However I do get a seg fault, which I think is due to my inability to compile openmm with -std=c++11. I posted about my problem on the openmm forum.

[Michael Sherman]

Hi, Sam. I think you may not know one of the bizarre quirks of C++: despite appearances, code like

Code: Select all

    MyType thing = something;

does not invoke the assignment operator. It invokes the copy constructor, that is, other than some technical details having to do with conversion, the above code is actually the same as:

Code: Select all

    MyType thing(something);

On the other hand, the following code does invoke the assignment operator:

Code: Select all

    MyType thing;
    thing = something;

The difference is whether the "=" is being used in a declaration, or as a separate statement.

That's why fiddling with the assignment operator didn't affect your problem, which had to do with a copy constructor.

Regards,
Sherm