Details
Critical
Description
http://buildbot.askmonty.org/buildbot/builders/kvm-bintar-centos5-amd64/builds/829/steps/compile/logs/stdio
http://buildbot.askmonty.org/buildbot/builders/kvm-deb-debian6-amd64/builds/3172/steps/compile/logs/stdio
http://buildbot.askmonty.org/buildbot/builders/kvm-deb-lucid-amd64/builds/4028/steps/compile/logs/stdio
It looks approximately like this, with some variations
standard input}: Assembler messages:
{standard input}:28252: Error: open CFI at the end of file; missing .cfi_endproc directive
gcc-4.4.real: Internal error: Killed (program cc1)
Please submit a full bug report.
See <file:///usr/share/doc/gcc-4.4/README.Bugs> for instructions.
make[3]: *** [storage/mroonga/vendor/groonga/lib/CMakeFiles/libgroonga.dir/expr.c.o] Error 1
make[3]: *** Waiting for unfinished jobs....
Given the list of platforms, I guess they all feature pretty old compilers, maybe that's the distinction.
Gliffy Diagrams
Attachments
Issue Links
- blocks
-
MDEV-7069 Fix buildbot failures in main server trees
-
- Stalled
-
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Please disable building Mroonga on these platforms for now. We are planning to decrease memory usage for optimization.
I can confirm, increasing the VM memory from 2 Gb to 3 Gb solves the problem. Other VMs also run on 2 Gb, apparently these systems are more OM-consuming on some reason.
I presume you are planning to make changes regardless of this report, so I'm assigning it back to myself (and maybe later to somebody else) to solve the immediate problem in buildbot.
Kristian increased the default amount of memory runvm from 2 Gb to 3 Gb, it solved the problem.
This is even worse when compiling with clang. On FreeBSD 10 (clang 3.3 / 3.4) memory consumption of the cc process during build increases to > 6GB and I get no working binary (that could have other reasons beside mem usage as well). There's also a groonga port for FreeBSD which behaves the same.
libtool: compile: cc -DHAVE_CONFIG_H -D_REENTRANT -DGRN_DLL_FILENAME=L\"libgroonga-0.dll\" -DGRN_PLUGINS_DIR=\"/usr/local/lib/groonga/plugins\" -DGRN_RELATIVE_PLUGINS_DIR=\"lib/groonga/plugins\" -DGRN_RUBY_SCRIPTS_DIR=\"/usr/local/lib/groonga/scripts/ruby\" -DGRN_RELATIVE_RUBY_SCRIPTS_DIR=\"lib/groonga/scripts/ruby\" -DGRN_LOG_PATH=\"/var/log/groonga.log\" -DGRN_DEFAULT_DOCUMENT_ROOT=\"/usr/local/share/groonga/html/admin\" -DGRN_DEFAULT_RELATIVE_DOCUMENT_ROOT=\"share/groonga/html/admin\" -DGRN_DAT_EXPORT -I.. -I../include -I/usr/local/include -fno-strict-aliasing -I/usr/local/include -O2 -pipe -fstack-protector -fno-strict-aliasing -Wall -Wextra -Wno-unused-parameter -Wno-sign-compare -Wno-pointer-sign -Wno-missing-field-initializers -Wformat=2 -Wstrict-aliasing=2 -Wdisabled-optimization -Wfloat-equal -Wpointer-arith -Wdeclaration-after-statement -Wbad-function-cast -Wcast-align -Wredundant-decls -Wwrite-strings -MT nfkc.lo -MD -MP -MF .deps/nfkc.Tpo -c nfkc.c -o nfkc.o >/dev/null 2>&1
It seems that these platform have too small memory for building Groonga with optimization.