Discussion:
Bug#849657: [Ceph-maintainers] Bug#849657: ceph: FTBFS on mips(el): g++: virtual memory exhausted: Cannot allocate memory
(too old to reply)
Gaudenz Steinlin
2016-12-29 20:10:01 UTC
Permalink
Hi Emilio
Source: ceph
Version: 10.2.5-2
Severity: serious
g++ -DHAVE_CONFIG_H -I. -D__CEPH__ -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE -D__STDC_FORMAT_MACROS -D_GNU_SOURCE -DCEPH_LIBDIR=\"/usr/lib/mipsel-linux-gnu\" -DCEPH_PKGLIBDIR=\"/usr/lib/mipsel-linux-gnu/ceph\" -DGTEST_USE_OWN_TR1_TUPLE=0 -D_REENTRANT -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/nss -I/usr/include/nspr -Wall -Wtype-limits -Wignored-qualifiers -Winit-self -Wpointer-arith -Werror=format-security -fno-strict-aliasing -fsigned-char -rdynamic -ftemplate-depth-1024 -Wnon-virtual-dtor -Wno-invalid-offsetof -O2 -g -pipe -Wall -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -fPIE -fstack-protector-strong -Wstrict-null-sentinel -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. -fstack-protector-strong -Wformat -Werror=format-security -c -o tools/rbd/action/Resize.o tools/rbd/action/Resize.cc
virtual memory exhausted: Cannot allocate memory
Makefile:24792: recipe for target
'test/encoding/ceph_dencoder-ceph_dencoder.o' failed
I already noticed this and tried to contact ***@buildd.debian.org and
***@buildd.debian.org. Unfortunately nobody responded yet, so I don't
know if the message was even received or not. AFAIK these are the
correct contact points for buildd issues.

I don't think there is much I can do about this bug and I'm not
convinced this is a issue in ceph. If the buildds are unable to build
the package we can either completely remove ceph for mips/mipsel or try
to only build the client part and have a reduced set of packages on
these architectures.

The second option would have the advantage that no changes to the
reverse dependencies (notably qemu) are needed.

Gaudenz
--
PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5
Aurelien Jarno
2017-01-04 14:30:01 UTC
Permalink
Post by Gaudenz Steinlin
Hi Emilio
Source: ceph
Version: 10.2.5-2
Severity: serious
g++ -DHAVE_CONFIG_H -I. -D__CEPH__ -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE -D__STDC_FORMAT_MACROS -D_GNU_SOURCE -DCEPH_LIBDIR=\"/usr/lib/mipsel-linux-gnu\" -DCEPH_PKGLIBDIR=\"/usr/lib/mipsel-linux-gnu/ceph\" -DGTEST_USE_OWN_TR1_TUPLE=0 -D_REENTRANT -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/nss -I/usr/include/nspr -Wall -Wtype-limits -Wignored-qualifiers -Winit-self -Wpointer-arith -Werror=format-security -fno-strict-aliasing -fsigned-char -rdynamic -ftemplate-depth-1024 -Wnon-virtual-dtor -Wno-invalid-offsetof -O2 -g -pipe -Wall -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -fPIE -fstack-protector-strong -Wstrict-null-sentinel -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. -fstack-protector-strong -Wformat -Werror=format-security -c -o tools/rbd/action/Resize.o tools/rbd/action/Resize.cc
virtual memory exhausted: Cannot allocate memory
Makefile:24792: recipe for target
'test/encoding/ceph_dencoder-ceph_dencoder.o' failed
know if the message was even received or not. AFAIK these are the
correct contact points for buildd issues.
That is the correct address for a buildd issue. I am currently processing
all the mails accumulated during the holiday season, sorry that I missed
it.
this. Added to Cc.
Post by Gaudenz Steinlin
I don't think there is much I can do about this bug and I'm not
convinced this is a issue in ceph. If the buildds are unable to build
the package we can either completely remove ceph for mips/mipsel or try
to only build the client part and have a reduced set of packages on
these architectures.
IIRC there are some flags you can pass to reduce memory usage. Most notably
ggc-min-expand (which is going to be changed in GCC itself, but afaik it hasn't
happened yet). So you could try adding
--param ggc-min-expand=10
to CFLAGS/CXXFLAGS.
I'd try that before thinking about removing the package from mips.
The problem is indeed a memory issue, not that the buildd doesn't have
enough memory, but just that you can allocate only 2GB per process on a
32-bit MIPS machine. As Emilio said, the above GCC flag should help to
reduce the memory usage by running the garbage collector more often.

However gcc 6.3 seems to have improved the situation a bit, so I given
back the packages, I hope they will build now. Otherwise I have a patch
ready to change the GCC defaults. That said GCC upstream consider it's a
bug in the garbage collector [1], so that should be fixed instead and the
patch should be considered as a temporary workaround.

Aurelien

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78971
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
***@aurel32.net http://www.aurel32.net
Emilio Pozuelo Monfort
2017-01-05 13:40:01 UTC
Permalink
Hi
Post by Aurelien Jarno
The problem is indeed a memory issue, not that the buildd doesn't have
enough memory, but just that you can allocate only 2GB per process on a
32-bit MIPS machine. As Emilio said, the above GCC flag should help to
reduce the memory usage by running the garbage collector more often.
However gcc 6.3 seems to have improved the situation a bit, so I given
back the packages, I hope they will build now. Otherwise I have a patch
ready to change the GCC defaults. That said GCC upstream consider it's a
bug in the garbage collector [1], so that should be fixed instead and the
patch should be considered as a temporary workaround.
Aurelien thanks for taking care and resheduling the build. Unfortunately
this did not solve the problem. But setting the following variables
export DEB_CFLAGS_MAINT_APPEND= --param ggc-min-expand=10 -O1
export DEB_CXXFLAGS_MAINT_APPEND= --param ggc-min-expand=10 -O1
export DEB_CFLAGS_MAINT_STRIP= -O2
export DEB_CXXFLAGS_MAINT_STRIP= -O2
But unfortunately the build fails at another point. See the log below.
I'm not sure how to fix this. If I understand it right these atomic
operations are just not supported on mipsel[1]. Or is there a way to make
them work?
They are supported. You are probably missing -latomic.

Cheers,
Emilio
Gaudenz Steinlin
2017-01-08 12:00:01 UTC
Permalink
Post by Emilio Pozuelo Monfort
Hi
Post by Aurelien Jarno
The problem is indeed a memory issue, not that the buildd doesn't have
enough memory, but just that you can allocate only 2GB per process on a
32-bit MIPS machine. As Emilio said, the above GCC flag should help to
reduce the memory usage by running the garbage collector more often.
However gcc 6.3 seems to have improved the situation a bit, so I given
back the packages, I hope they will build now. Otherwise I have a patch
ready to change the GCC defaults. That said GCC upstream consider it's a
bug in the garbage collector [1], so that should be fixed instead and the
patch should be considered as a temporary workaround.
Aurelien thanks for taking care and resheduling the build. Unfortunately
this did not solve the problem. But setting the following variables
export DEB_CFLAGS_MAINT_APPEND= --param ggc-min-expand=10 -O1
export DEB_CXXFLAGS_MAINT_APPEND= --param ggc-min-expand=10 -O1
export DEB_CFLAGS_MAINT_STRIP= -O2
export DEB_CXXFLAGS_MAINT_STRIP= -O2
But unfortunately the build fails at another point. See the log below.
I'm not sure how to fix this. If I understand it right these atomic
operations are just not supported on mipsel[1]. Or is there a way to make
them work?
They are supported. You are probably missing -latomic.
You are right, using -latomic fixes the issue. If I understand this
right -latomic "emulates" the atomic operation if there is no direct
support in the processor for it.

What's the correct way to detect if -latomic is needed? Or is it safe to
use -latomic everywhere on all architectures and let the linker/compiler
do the right thing? I'd like to patch the build system in a way that can
be sent upstream instead of working around it.

Gaudenz
--
PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5
Debian Bug Tracking System
2017-01-08 21:10:02 UTC
Permalink
Your message dated Sun, 08 Jan 2017 21:04:00 +0000
with message-id <E1cQKdE-000I2Z-***@fasolo.debian.org>
and subject line Bug#849657: fixed in ceph 10.2.5-4
has caused the Debian Bug report #849657,
regarding ceph: FTBFS on mips(el): g++: virtual memory exhausted: Cannot allocate memory
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ***@bugs.debian.org
immediately.)
--
849657: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849657
Debian Bug Tracking System
Contact ***@bugs.debian.org with problems
Loading...