Tudat / tudat

NOTE: This Tudat version is no longer supported. See https://docs.tudat.space/en/stable/ and https://github.com/tudat-team/tudat-bundle for the new version
BSD 3-Clause "New" or "Revised" License
87 stars 143 forks source link

Error "out of memory allocating 2334160 bytes" during compilation #261

Closed ggranato92 closed 7 years ago

ggranato92 commented 7 years ago

Hi Dominic,

After our meeting today I have restarted the computer and unfortunately the same error occurs. However, I think I know where the problem comes from: some days ago when I opened Qt and was still working on writing the code, it asked for an update and I did it. Maybe some settings have changed, what do you think? I have clicked on the manage kits option, build and run, and I am having a look at the settings but everything seems fine...here I am attaching the screenshot. Could you please have a look and tell me if there is something wrong?

manage_kits_qt

Thank you very much, Giovanni

DominicDirkx commented 7 years ago

Hi Giovanni,

The only thing I can think of is that the version of MinGW changed when updating. What exactly was updated? Do you have any options besides 5.3.0?

Cheers,

Dominic

ggranato92 commented 7 years ago

Hi Dominic,

I have another option which is MinGW 4.9.2. I have tried it but no luck..the error is still the same. I don't know what was exactly updated unfortunately. However I have noticed that among the build settings the Compile_high_accuracy_estimation_tests was on again while I do remember that we turned it off and so I have. I have compiled everything again but it is giving me the same error..shall I try to delete all the build folder and compile everything again from the start?

DominicDirkx commented 7 years ago

In your 'build&run'-> compilers tab in teh above screenshot, you should be able to find the executables for the different MinGW versions.

When running CMake, you should see somewhere in the output which compiler executable is used, Is the 4.9.2 set? If not, you may need to remove the CMakeCache.txt file, as well as close/reopen Qt. Additionally, it is possible that you will need to recompile boost (did you when changing compiler?). If you recompile boost, relocate your current boost folder, so you can easily switch between compilers without having to recompile boost every time.

ggranato92 commented 7 years ago

When I run CMake I see that the new chosen compiler is used (4.9.2). However, during the process boost is not recompiled. After changing the compiler and building everything again, I'm getting some issues like this ones:

C:\tudatBundle\boost\stage\lib\libboost_unit_test_framework-mt.a(test_tree.o):-1: error: duplicate section `.rdata$_ZTSN5boost16exception_detail19error_info_injectorINS_17bad_function_callEEE[__ZTSN5boost16exception_detail19error_info_injectorINS_17bad_function_callEEE]' has different size

C:\tudatBundle\tudat\Tudat\Astrodynamics\Aerodynamics\UnitTests\unitTestAerodynamicsNamespace.cpp:-1: error: undefined reference to `boost::unit_test::ut_detail::normalize_test_case_name(boost::unit_test::basic_cstring)'

unit_test_main.cpp:-1: error: undefined reference to `std::__cxx11::basic_string<char, std::char_traits, std::allocator >::append(char const*)'

How can I choose to compile boost again? Shall I empty the boost folder in my tudatBundle folder and run CMake again? Looks like the boost building process and the location of the folder is all automated

DominicDirkx commented 7 years ago

This is indeed due to this boost incompatibility. As I noted in my previous post, move your current boost folder somewhere else (or rename it). If CMake sees that the tudatBundle/boost folder is no longer there, it will recompile boost..

ggranato92 commented 7 years ago

I have recompiled boost but I still get the same previous errors denoted as "duplicate section" when I compile everything..

DominicDirkx commented 7 years ago

This looks like the compiler you are using to compile boost, and the compiler for Tudat are different. Are you sure that you have correctly switched the compiler?

By the way, I compiled the multiArcStateEstimation test (changing the template arguments to double, double, double) on an old Windows computer (8 GB RAM), and it went fine. It's using MinGW 5.3 and boost 1.60.

I'm now updating all the other code to see how it compiles, but this computer is very slow, so it may be a while.

DominicDirkx commented 7 years ago

The state estimation example is also failing to build for me.

I've done some googling, and it turns out that MinGW32 only allows you to allocate 2 GB. There's a trick to increase it to 4GB, apparently.

In the compiler.cmake files (both in tudatBundle/external and tudatExampleApplications), after you have your boost incompatibility fixed, try adding:

if (MINGW) set(CMAKE_EXE_LINKER_FLAGS "-Wl,--large-address-aware") endif ()

at the end of the file. Keep it outside of any if statements, just to make sure it gets parsed.

ggranato92 commented 7 years ago

Hi Dominic,

Thank you for your help.

After fixing the boost incompatibility, modifying the compiler.cmake files, I am getting new issues when I compile everything. The type of errors are “undefined reference” and the problems occurring are related to the header and cpp files in the sofainterface folder. Seems that the Earth orientation data is not recognized. I am attaching the compile output here:

Compile_output.txt

The problems occur when compiling the SingleSatellitePropagator application..even though I have made sure that in the list of libraries there is everything needed ( I have looked into the CMakeLists file )

On the other hand, I have tried to compile only the EarthOrbiterStateEstiation but the memory error still appears although I have made those changes you have suggested

DominicDirkx commented 7 years ago

Are you sure that sofa has (re)compiled with the new settings?

Do any of tests that do no require sofa build correctly?

I'm adding @magnific0 to this issue, I talked about the out of memory issue with him yesterday, and he might have a fix.

DominicDirkx commented 7 years ago

Hi guys,

I installed Windows 10 in a virtual machine, and managed to reproduce these errors. The good news is, I also managed to solve them (at least for my installation), I've added:

if( MINGW )
  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -ftrack-macro-expansion=0")
  set(CMAKE_EXE_LINKER_FLAGS "-Wl,--large-address-aware")
endif()

to the compiler.cmake files. We tried the second command on Giovanni's machine yesterday, to no effect, but I'm not sure if the argument got parsed correctly. After I changed my compiler.cmake files, all relevant tudat libraries recompiled, which I'm not sure was done on Giovanni's machine. Could either or both of you verify if this fix works for you?

If it does, we need to add it to the compiler.cmake in a proper way. The good news is that all unit tests compile (even the high accuracy estimation tests).

The compiler I use is MinGW 5.3.0

ggranato92 commented 7 years ago

Hi all,

After trying the suggested fix I am not getting any memory issues on my windows installation of the tudat (for instance the application that I wrote about a multiarc state estimation is now correctly compiled). However, the new issues are related to sofa as I have mentioned some comments ago. The type of error is "undefined reference to" and there is a list of reference frames identifications which are not recognized.

Due to the very many problems that I have been having with windows, I have recently installed Linux on a virtual machine and have started working on there. The Linux installation is working perfectly.

Best regards, Giovanni

DominicDirkx commented 7 years ago

Hi Giovanni,

Could you post a text file with the exact error output from Windows?

ggranato92 commented 7 years ago

The error output is the following:

Error_output.txt

It looks like the exact compile error output that I attached a few comments ago

DominicDirkx commented 7 years ago

Good, thank you, just wanted to make sure.

DominicDirkx commented 7 years ago

This has been resolved with updates to development-json branch.