Quuxplusone / LLVMBugzillaTest

0 stars 0 forks source link

clang gets killed by the OOM manager when building a source file #22198

Open Quuxplusone opened 9 years ago

Quuxplusone commented 9 years ago
Bugzilla Link PR22199
Status NEW
Importance P normal
Reported by Raphael Kubo da Costa (:rakuco) (rakuco@FreeBSD.org)
Reported on 2015-01-11 15:50:24 -0800
Last modified on 2015-12-10 02:12:43 -0800
Version trunk
Hardware PC FreeBSD
CC dgregor@apple.com, dimitry@andric.com, llvm-bugs@lists.llvm.org, rafael@espindo.la, Woebbeking@web.de
Fixed by commit(s)
Attachments gmic-7c2be6.sh (1606 bytes, application/x-shellscript)
Blocks
Blocked by
See also

The attached preprocessed file causes clang 3.4.1, 3.5.0 and trunk (r225161) on Linux and FreeBSD to use a lot of CPU and then get killed by the OOM manager after a while.

The preprocessed file comes from Calligra 2.8.6: http://quickgit.kde.org/?p=calligra.git&a=blob&h=92d5f4f69addcf6e568af62150b048950fb10659&hb=3292de7f753604d37db694e668c0389a0cb3fbc7&f=krita%2Fplugins%2Fextensions%2Fgmic%2Fgmic.cpp

Quuxplusone commented 9 years ago

The attachment was too big for Bugzilla. I've hosted it in http://people.freebsd.org/~rakuco/gmic-096c5a.tar.xz

Quuxplusone commented 9 years ago

_Bug 22187 has been marked as a duplicate of this bug._

Quuxplusone commented 9 years ago

Raphael, please also post the .sh file, since that contains the exact flags used. Otherwise it might be difficult to reproduce the issue.

Quuxplusone commented 9 years ago

Attached gmic-7c2be6.sh (1606 bytes, application/x-shellscript): Another .sh

Quuxplusone commented 9 years ago

BTW, I can reproduce this with 3.4, 3.5 and upcoming 3.6 (all packages from Debian Sid).

Quuxplusone commented 9 years ago

Please disregard my last comment. The .tar.xz file contains both the .cpp and .sh files. The full command line used is:

clang -cc1 -triple x86_64-unknown-freebsd11.0 -emit-obj -disable-free -main-file-name gmic.cpp -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -gdwarf-2 -D "CAN_USE_QTWEBKIT" -D "COMPILING_TESTS" -D "KDE4_CMAKE_TOPLEVEL_DIR_LENGTH=10" -D "KDE_DEPRECATED_WARNINGS" -D "QT_NO_CAST_TO_ASCII" -D "QT_NO_STL" -D "QT_USE_FAST_CONCATENATION" -D "QT_USE_FAST_OPERATOR_PLUS" -D "SHOULD_BUILD_FONT_CONVERSION" -D "SHOULD_BUILD_RDF" -D "_REENTRANT" -D "cimg_display=0" -D "cimg_use_fftw3" -D "cimg_use_fftw3_singlethread" -D "cimg_use_vt100" -D "gmic_build" -D "gmic_float_only" -U QT_NO_EXCEPTIONS -D "NDEBUG" -D "QT_NO_DEBUG" -D "_LARGEFILE64_SOURCE" -O2 -Wnon-virtual-dtor -Wno-long-long -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -Woverloaded-virtual -Werror=return-type -Wno-return-type-c-linkage -fdeprecated-macro -ferror-limit 19 -fmessage-length 162 -fvisibility hidden -fvisibility-inlines-hidden -mstackrealign -fobjc-runtime=gnustep -fcxx-exceptions -fexceptions -fno-common -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -x c++ gmic-096c5a.cpp

Quuxplusone commented 9 years ago
Setting a ulimit of 768MB gives an indication of which pass is eating the
memory:

Stack dump:
0.      Program arguments: /share/dim/llvm/225622-trunk-freebsd11-i386-aconf-
rel-2/bin/clang -cc1 -triple x86_64-unknown-freebsd11.0 -emit-obj -disable-free
-mrelocation-model pic -pic-level 2 -mdisable-fp-elim -mconstructor-aliases -
munwind-tables -target-cpu x86-64 -O1 -fdeprecated-macro -fvisibility hidden -
fvisibility-inlines-hidden -mstackrealign -fcxx-exceptions -fexceptions -fno-
common -fdiagnostics-show-option -x c++ gmic-096c5a.ii
1.      <eof> parser at end of file
2.      Per-module optimization passes
3.      Running pass 'CallGraph Pass Manager' on module 'gmic-096c5a.ii'.
4.      Running pass 'Value Propagation' on function
'@_ZN4gmic6_parseIfEERS_RKN12cimg_library8CImgListIcEERjRNS3_IT_EERS4_Pj'
Quuxplusone commented 9 years ago
Note that the function in question is:

gmic& gmic::_parse<float>(cimg_library::CImgList<char> const&, unsigned int&,
cimg_library::CImgList<float>&, cimg_library::CImgList<char>&, unsigned int*)

and this function is about ~7800 lines preprocessed.  Maybe the function's
large size blows up the value propagation stage.
Quuxplusone commented 9 years ago
(In reply to comment #7)
> Setting a ulimit of 768MB gives an indication of which pass is eating the
> memory:

That could be too less memory. On x86_64 Clang is at about 1GB for a some time,
then has a peak at 4 or 5 GB, falls down to 1 GB again to go up to 16 GB peak
after some more time.
Quuxplusone commented 9 years ago

FWIW, this is version 1.5.8.4 of CImg. Version 1.5.9.0 also gets killed here, but 1.6.0 takes a few minutes to build but does not crash.