Summary: | sys-devel/llvm-3.1-r2 leads to segmentation faults in sys-devel/clang | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Severin Strobl <gentoo> |
Component: | [OLD] Development | Assignee: | Michał Górny <mgorny> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | alexxy, ambrop7, dschridde+gentoobugs, kripton, m.bannerman, marek, mattst88, ryao, voyageur |
Priority: | Normal | Keywords: | PMASKED |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 408963 |
Description
Severin Strobl
2012-07-19 11:26:33 UTC
Just confirming that I have trouble with -r2 as well. I have similar stack dumps from the compiler (see below) and downgrading to -r1 removed the issues. No minimal example available, sorry, but it does fail while compiling boost so its not just my dodgy code :-) libLLVM-3.1.so 0x00007f48c6dd7bef 1 libLLVM-3.1.so 0x00007f48c6dd81ba 2 libpthread.so.0 0x00007f48c68ae420 3 libLLVM-3.1.so 0x00007f48c6d4dc6d 4 libLLVM-3.1.so 0x00007f48c6d52b2c 5 libLLVM-3.1.so 0x00007f48c6d54e3a 6 libLLVM-3.1.so 0x00007f48c72dc32c llvm::MPPassManager::runOnModule(llvm::Module&) + 508 7 libLLVM-3.1.so 0x00007f48c72dc40f llvm::PassManagerImpl::run(llvm::Module&) + 111 8 clang 0x00000000006a7d9b clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::Module*, clang::BackendAction, llvm::raw_ostream*) + 2075 9 clang 0x00000000006a5c27 10 clang 0x00000000007f1dff clang::ParseAST(clang::Sema&, bool, bool) + 415 11 clang 0x00000000006a4b93 clang::CodeGenAction::ExecuteAction() + 51 12 clang 0x000000000056c321 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 273 13 clang 0x0000000000552a18 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1240 14 clang 0x00000000005493ea cc1_main(char const**, char const**, char const*, void*) + 6378 15 clang 0x00000000005518cc main + 5900 16 libc.so.6 0x00007f48c62272ad __libc_start_main + 253 17 clang 0x0000000000547959 I'm also having issues with llvm-3.1-r2. It doesn't crash, but it makes clang miscompile some software of mine ( http://code.google.com/p/badvpn/wiki/NCD ). My interpreter segfaults trying to execute any script. Reverting to llvm-3.1-r1 fixes it. I've also tried recompiling clang after upgrading to llvm-3.1-r2, but it didn't help. What are your USE? Could you post the 'emerge -pv llvm clang'? Sure, here we go: sys-devel/llvm-3.1-r2 USE="libffi vim-syntax -debug -gold -multitarget -ocaml -test -udis86" sys-devel/clang-3.1-r5 USE="static-analyzer -debug -multitarget -test" (In reply to comment #4) > Sure, here we go: > > sys-devel/llvm-3.1-r2 USE="libffi vim-syntax -debug -gold -multitarget > -ocaml -test -udis86" > > sys-devel/clang-3.1-r5 USE="static-analyzer -debug -multitarget -test" Ok, are the others reproducing it using USE=-multitarget? Maybe that's because we didn't notice... s/because/why/, it's too late for me... I'm using ~amd64; here are the use flags: r sys-devel/llvm:0::ambro 3.1-r1 to ::installed replacing 3.1-r1 -debug gold libffi -multitarget -ocaml -udis86 -vim-syntax (-test) build_options: symbols=split -optional_tests -trace -preserve_work Reasons: target, sys-devel/clang r sys-devel/clang:0::gentoo 3.1-r5 to ::installed replacing 3.1-r5 -debug -multitarget static-analyzer (-test) build_options: symbols=split -optional_tests -trace -preserve_work Reasons: target cave info: Package Manager Information: Package Name paludis Package Version 0.76.0 Build Date 2012-06-28T12:05:20+0200 Built with CXX x86_64-pc-linux-gnu-g++ 4.7.1 Built with CXXFLAGS -O2 -march=core2 -pipe -pedantic Built with LDFLAGS -Wl,-O1 -Wl,--as-needed Environment Information: Format paludis Config dir /etc/paludis Root / System Root / World file /var/db/pkg/world Repository gentoo: format e location /usr/portage builddir /var/tmp/paludis cache /usr/portage/metadata/md5-cache distdir /var/paludis/distfiles eapi_when_unknown 0 eapi_when_unspecified 0 eclassdirs /usr/portage/eclass layout traditional manifest_hashes SHA256 SHA512 WHIRLPOOL names_cache /var/cache/paludis/names newsdir /usr/portage/metadata/news profile_eapi_when_unspecified 0 profile_layout traditional profiles /usr/portage/profiles/default/linux/amd64/10.0/desktop /etc/paludis/profile securitydir /usr/portage/metadata/glsa setsdir /usr/portage/sets sync gentoo://http://distfiles.gentoo.org/snapshots/portage-latest.tar.bz2 sync_options thin_manifests false use_manifest use write_cache /var/empty Package information app-shells/bash 4.2_p36 dev-java/java-config (none) dev-lang/python 2.6.8 2.7.3-r2 3.1.5 3.2.3-r1 dev-util/ccache (none) dev-util/cmake 2.8.8-r3 dev-util/pkgconfig 0.27 sys-apps/baselayout 2.1-r1 sys-apps/openrc 0.10.5 sys-apps/sandbox 2.6 sys-devel/autoconf 2.13 2.69 sys-devel/automake 1.11.6 1.12.2 1.9.6-r3 sys-devel/binutils 2.22-r1 sys-devel/gcc 4.4.7 4.5.4 4.6.3 4.7.1 sys-devel/gcc-config 1.7.3 sys-devel/libtool 2.4.2 sys-devel/make 3.82-r3 sys-freebsd/freebsd-lib (none) sys-kernel/linux-headers 3.4-r1 sys-libs/glibc 2.14.1-r3 sys-libs/uclibc (none) I hit this too with 3.1-r2. Would someone provide a simple set of instructions to use to reproduce this? Ideally, I would like something like `env CC=clang CXX=clang++ emerge --oneshot =category/name-version` that I could use to reproduce it. CC=clang CXX=clang++ ebuild /usr/portage/media-libs/mesa/mesa-8.0.3.ebuild compile (In reply to comment #10) > CC=clang CXX=clang++ ebuild /usr/portage/media-libs/mesa/mesa-8.0.3.ebuild > compile I can reproduce that with patched llvm and older clang. Did anyone try newer clang and older llvm? Yes tried that, sys-devel/clang-3.1-r5 in combination with sys-devel/llvm-3.1-r1 did not produce any segfaults in my case. I've masked the relevant versions. Alexxy, would you please take this bugreport to the patch authors? (In reply to comment #12) > Yes tried that, sys-devel/clang-3.1-r5 in combination with > sys-devel/llvm-3.1-r1 did not produce any segfaults in my case. This is my experience too. I looked through the patches that were introduced in sys-devel/llvm-3.1-r2 and I did not see any obvious cause. We probably should contact the author to have him look at this. sys-devel/clang-3.1-r4 w/ sys-devel/llvm-3.1-r1 compiles the following minimal example just fine but fails w/ the backtrace in static analyzer mode: % cat test1.c #define NULL ((void *)0) static void bar(void) { int rv; if (0 != rv) ; } static void foo(void) { bar(); } % clang -c test1.c % clang --analyze test1.c 0 libLLVM-3.1.so 0x00007fb79a592fdf 1 libLLVM-3.1.so 0x00007fb79a593449 2 libpthread.so.0 0x00007fb79a07fce0 3 clang 0x0000000000bd49a0 4 clang 0x0000000000bde94c clang::ento::GRBugReporter::GeneratePathDiagnostic(clang::ento::PathDiagnostic&, llvm::SmallVectorImpl<clang::ento::BugReport*>&) + 12364 5 clang 0x0000000000bdb09b clang::ento::BugReporter::FlushReport(clang::ento::BugReportEquivClass&) + 3627 6 clang 0x0000000000bdf118 clang::ento::BugReporter::FlushReports() + 1112 7 clang 0x0000000000ace84d 8 clang 0x0000000000acf212 9 clang 0x0000000000ad62e9 10 clang 0x00000000007bd31d clang::ParseAST(clang::Sema&, bool, bool) + 461 11 clang 0x000000000055e6a3 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 259 12 clang 0x0000000000547942 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1010 13 clang 0x000000000053eab5 cc1_main(char const**, char const**, char const*, void*) + 8853 14 clang 0x0000000000546b7f main + 7151 15 libc.so.6 0x00007fb7999e53ed __libc_start_main + 237 16 clang 0x000000000053c699 Stack dump: 0. Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu -analyze -disable-free -disable-llvm-verifier -main-file-name test1.c -analyzer-store=region -analyzer-opt-analyze-nested-blocks -analyzer-eagerly-assume -analyzer-ipa=inlining -analyzer-checker=core -analyzer-checker=unix -analyzer-checker=deadcode -analyzer-checker=security.insecureAPI.UncheckedReturn -analyzer-checker=security.insecureAPI.getpw -analyzer-checker=security.insecureAPI.gets -analyzer-checker=security.insecureAPI.mktemp -analyzer-checker=security.insecureAPI.mkstemp -analyzer-checker=security.insecureAPI.vfork -analyzer-output plist -w -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.22 -momit-leaf-frame-pointer -resource-dir /usr/bin/../lib/clang/3.1 -fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.1/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdebug-compilation-dir /tmp -ferror-limit 19 -fmessage-length 136 -mstackrealign -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fdiagnostics-show-option -fcolor-diagnostics -o test.plist -x c test1.c 1. <eof> parser at end of file clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: clang frontend command failed due to signal (use -v to see invocation) clang: note: diagnostic msg: Please submit a bug report to http://llvm.org/bugs/ and include command line arguments and all diagnostic information. clang: note: diagnostic msg: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /tmp/test-hrryVh.i clang: note: diagnostic msg: /tmp/test-hrryVh.sh zsh: exit 254 clang --analyze test1.c Slightly modifying the testcase I've been also able to get the different backtrace: % cat test2.c #define NULL ((void *)0) typedef unsigned long int pthread_t; int pthread_join(pthread_t thread, void **retval); void durr(pthread_t t) { int rv; void *trv = NULL; if (0 != (rv = pthread_join(t, &trv))) ; if (0 != rv && NULL != trv) ; } void hurr(pthread_t t) { durr(t); } % clang --analyze test2.c 0 libLLVM-3.1.so 0x00007f3fdf6d9fdf 1 libLLVM-3.1.so 0x00007f3fdf6da449 2 libpthread.so.0 0x00007f3fdf1c6ce0 3 clang 0x0000000000c18bc7 clang::ento::ExprEngine::processCallExit(clang::ento::ExplodedNode*) + 1511 4 clang 0x0000000000bf6051 clang::ento::CoreEngine::dispatchWorkItem(clang::ento::ExplodedNode*, clang::ProgramPoint, clang::ento::WorkListUnit const&) + 465 5 clang 0x0000000000bf6122 clang::ento::CoreEngine::ExecuteWorkList(clang::LocationContext const*, unsigned int, llvm::IntrusiveRefCntPtr<clang::ento::ProgramState const>) + 194 6 clang 0x0000000000ace816 7 clang 0x0000000000acf212 8 clang 0x0000000000ad62e9 9 clang 0x00000000007bd31d clang::ParseAST(clang::Sema&, bool, bool) + 461 10 clang 0x000000000055e6a3 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 259 11 clang 0x0000000000547942 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1010 12 clang 0x000000000053eab5 cc1_main(char const**, char const**, char const*, void*) + 8853 13 clang 0x0000000000546b7f main + 7151 14 libc.so.6 0x00007f3fdeb2c3ed __libc_start_main + 237 15 clang 0x000000000053c699 Not sure though whether these two are related to the original issue. Well, the my issue is apparently unrelated: http://llvm.org/bugs/show_bug.cgi?id=12945 (In reply to comment #16) > Well, the my issue is apparently unrelated: > http://llvm.org/bugs/show_bug.cgi?id=12945 Would you file a separate bug report for this issue? ryao, you had a good idea :) After applying the cl-patches from llvm to clang-3.1-r5, CC=clang CXX=clang++ ebuild /usr/portage/media-libs/mesa/mesa-8.0.3.ebuild compile worked. This may need some further testing, but this sounds like we found the root cause. I updated clang-3.1-r5 ebuild to also apply llvm cl-patches, if someone can confirm llvm-3.1-r2/clang-3.1-r5 now works fine, I'll drop the mask and mark this as resolved :) (In reply to comment #19) > I updated clang-3.1-r5 ebuild to also apply llvm cl-patches, if someone can > confirm llvm-3.1-r2/clang-3.1-r5 now works fine, I'll drop the mask and mark > this as resolved :) I can confirm that the combination of sys-devel/llvm-3.1-r2 and sys-devel/clang-3.1-r5 works as expected for my test case. Anybody still encountering any problems with the updated version? I can confirm that clang-3.1-r5 with llvm-3.1-r2 fix the problem. Thanks! Unmasked then. |