[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Compiler runs out of memory when building a package



Hi.

I'm looking for a suggestion to fix a problem.

I uploaded a package, and it cleared NEW a few days ago. I now see that
it fails to build on most 32-bit arches becaues the compiler runs out of
memory. Logs:

  https://buildd.debian.org/status/package.php?p=gtsam

Arbitrary 32-bit log (armhf):

  https://buildd.debian.org/status/fetch.php?pkg=gtsam&arch=armhf&ver=4.2%7E9%2Bdfsg-2&stamp=1691926953&raw=0

I thought it maybe is due to doing too many things in parallel, but
building with -j1 doesn't fix it. I have boiled down the problem to
compiling a single source file. Unsuprisingly, this is a big generated
C++ source file used to define the Python interface. I can reproduce
this with a single compile command on abel.d.o (the
armhf porterbox):

  apt source gtsam

  cd gtsam-4.2~9+dfsg

  PYTHONPATH=wrap \
  python3 "wrap/scripts/pybind_wrap.py" \
    --src "gtsam/geometry/geometry.i" \
    --out geometry.cpp \
    --module_name gtsam \
    --top_module_namespaces gtsam \
    --ignore gtsam::Point2 gtsam::Point3 gtsam::ISAM2ThresholdMapValue gtsam::FactorIndices gtsam::FactorIndexSet gtsam::IndexPairSetMap gtsam::IndexPairVector gtsam::BetweenFactorPose2s gtsam::BetweenFactorPose3s gtsam::Point2Vector gtsam::Point2Pairs gtsam::Point3Pairs gtsam::Pose3Pairs gtsam::Pose3Vector gtsam::Rot3Vector gtsam::KeyVector gtsam::BinaryMeasurementsPoint3 gtsam::BinaryMeasurementsUnit3 gtsam::BinaryMeasurementsRot3 gtsam::DiscreteKey gtsam::KeyPairDoubleMap gtsam::gtsfm::MatchIndicesMap gtsam::gtsfm::KeypointsVector gtsam::gtsfm::SfmTrack2dVector \
    --template "python/gtsam/gtsam.tpl" \
    --is_submodule \
    --use-boost

  < cmake/dllexport.h.in sed \
  ' s/#cmakedefine/#define/g;
    s/@library_name@/GTSAM/g;
  ' > gtsam/dllexport.h

  < gtsam/config.h.in sed \
  ' s/#cmakedefine/#define/g;
    s/@GTSAM_VERSION_MAJOR@/4/g;
    s/@GTSAM_VERSION_MINOR@/2/g;
    s/@GTSAM_VERSION_PATCH@/0/g;
    s/@GTSAM_VERSION_NUMERIC@/40200/g;
    s/@GTSAM_VERSION_STRING@/4.2a9/g;
    s/@GTSAM_EIGEN_VERSION_WORLD@/3/g;
    s/@GTSAM_EIGEN_VERSION_MAJOR@/4/g;
    s/.*define .*_USE.*_MKL.*//g;
    s/.*define GTSAM_EIGEN_VERSION_MINOR.*//g;
    s/.*define GTSAM_ALLOCATOR_BOOSTPOOL.*//g;
    s/.*define GTSAM_ALLOCATOR_STL.*//g;
    s/.*define GTSAM_SLOW_BUT_CORRECT_BETWEENFACTOR.*//g;
    s/.*define GTSAM_USE_QUATERNIONS.*//g;
  ' > gtsam/config.h

  /usr/bin/c++ \
    -DBOOST_ALL_NO_LIB \
    -DBOOST_ATOMIC_DYN_LINK \
    -DBOOST_CHRONO_DYN_LINK \
    -DBOOST_DATE_TIME_DYN_LINK \
    -DBOOST_FILESYSTEM_DYN_LINK \
    -DBOOST_PROGRAM_OPTIONS_DYN_LINK \
    -DBOOST_REGEX_DYN_LINK \
    -DBOOST_SERIALIZATION_DYN_LINK \
    -DBOOST_SYSTEM_DYN_LINK \
    -DBOOST_THREAD_DYN_LINK \
    -DBOOST_TIMER_DYN_LINK \
    -Dgtsam_py_EXPORTS \
    -I"." \
    -I"CppUnitLite" \
    -isystem /usr/include/python3.11 \
    -isystem /usr/include/eigen3 \
    -g \
    -O2 \
    -fstack-protector-strong \
    -Wformat \
    -Werror=format-security \
    -Wdate-time \
    -D_FORTIFY_SOURCE=2 \
    -g \
    -DNDEBUG \
    -fPIC \
    -fvisibility=hidden \
    -o /tmp/tst.o \
    -c geometry.cpp

On abel.d.o this crunches for a while, and then says

  cc1plus: out of memory allocating 152612 bytes after a total of 59252736 bytes

I will report this upstream, but I don't yet know what to tell them. Any
suggestions here for debian and/or for upstream?

If I was upstream, I'd do a lot of this differently, but I'm not going
to ask them to majorly rearchitect their thing.

Thanks.


Reply to: