Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenMP crash #24037

Closed
ismail opened this issue May 26, 2015 · 17 comments
Closed

OpenMP crash #24037

ismail opened this issue May 26, 2015 · 17 comments
Labels
bugzilla Issues migrated from bugzilla clang Clang issues not falling into any other category

Comments

@ismail
Copy link
Contributor

ismail commented May 26, 2015

Bugzilla Link 23663
Resolution FIXED
Resolved on Jun 15, 2015 05:00
Version trunk
OS Linux
CC @alexey-bataev

Extended Description

Reduced from http://www.kevinbeason.com/smallpt/smallpt.txt

λ clang -v
clang version 3.7.0 (trunk 238128)
Target: x86_64-suse-linux
Thread model: posix
Found candidate GCC installation: /usr/lib64/gcc/x86_64-suse-linux/4.8
Selected GCC installation: /usr/lib64/gcc/x86_64-suse-linux/4.8
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64

λ cat t.cpp
struct t {
double x;
};

int main(){
int h;
t r;
#pragma omp parallel for schedule(dynamic, 1) private(r)
for (int y=0; y<h; y++){
}
}

λ clang++ -fopenmp -O2 t.cpp
clang-3.7: ../tools/clang/lib/CodeGen/CGCleanup.cpp:629: void clang::CodeGen::CodeGenFunction::PopCleanupBlock(bool): Assertio
n `!Scope.isNormalCleanup() || !HasPrebranchedFallthrough || (Scope.getNormalBlock() && FallthroughSource->getTerminator()->ge
tSuccessor(0) == Scope.getNormalBlock())' failed.
#​0 0x7f4f62bae778 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/opt/clang/lib64/libLLVMSupport.so.3.7+0xc7778)
#​1 0x7f4f62bafc0b (/opt/clang/lib64/libLLVMSupport.so.3.7+0xc8c0b)
#​2 0x7f4f610c9440 __restore_rt (/lib64/libc.so.6+0x33440)
#​3 0x7f4f610c93c7 __GI_raise /usr/src/debug/glibc-2.21/signal/../sysdeps/unix/sysv/linux/raise.c:55:0
#​4 0x7f4f610ca79a __GI_abort /usr/src/debug/glibc-2.21/stdlib/abort.c:80:0
#​5 0x7f4f610c22e6 __assert_fail_base /usr/src/debug/glibc-2.21/assert/assert.c:92:0
#​6 0x7f4f610c2392 (/lib64/libc.so.6+0x2c392)
#​7 0x7f4f5b9eb676 clang::CodeGen::CodeGenFunction::PopCleanupBlock(bool) (/opt/clang/lib64/libclangCodeGen.so.3.7+0xd4676)
#​8 0x7f4f5b9eb9d2 clang::CodeGen::CodeGenFunction::PopCleanupBlocks(clang::CodeGen::EHScopeStack::stable_iterator, unsigned lo
ng) (/opt/clang/lib64/libclangCodeGen.so.3.7+0xd49d2)
#​9 0x7f4f5baaee2d (/opt/clang/lib64/libclangCodeGen.so.3.7+0x197e2d)
#​10 0x7f4f5baabfc2 (/opt/clang/lib64/libclangCodeGen.so.3.7+0x194fc2)
#​11 0x7f4f5baca8ed (/opt/clang/lib64/libclangCodeGen.so.3.7+0x1b38ed)
#​12 0x7f4f5bac9cc2 clang::CodeGen::CodeGenFunction::EmitOMPWorksharingLoop(clang::OMPLoopDirective const&) (/opt/clang/lib64/libclangCodeGen.so.3.7+0x1b2cc2)
#​13 0x7f4f5bad2295 (/opt/clang/lib64/libclangCodeGen.so.3.7+0x1bb295)
#​14 0x7f4f5baad851 (/opt/clang/lib64/libclangCodeGen.so.3.7+0x196851)
#​15 0x7f4f5bac32cf clang::CodeGen::CodeGenFunction::GenerateCapturedStmtFunction(clang::CapturedStmt const&) (/opt/clang/lib64
/libclangCodeGen.so.3.7+0x1ac2cf)
#​16 0x7f4f5baa2be8 clang::CodeGen::CGOpenMPRuntime::emitParallelOutlinedFunction(clang::OMPExecutableDirective const&, clang::
VarDecl const*, llvm::function_ref<void (clang::CodeGen::CodeGenFunction&)> const&) (/opt/clang/lib64/libclangCodeGen.so.3.7+0
x18bbe8)
#​17 0x7f4f5bac7931 (/opt/clang/lib64/libclangCodeGen.so.3.7+0x1b0931)
#​18 0x7f4f5bacc243 clang::CodeGen::CodeGenFunction::EmitOMPParallelForDirective(clang::OMPParallelForDirective const&) (/opt/c
lang/lib64/libclangCodeGen.so.3.7+0x1b5243)
#​19 0x7f4f5bab8b54 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) (/opt/clang/lib64/libclangCodeGen.so.3.7+0x1a
1b54)
#​20 0x7f4f5bac02dc clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt const&, bool, clang::Code
Gen::AggValueSlot) (/opt/clang/lib64/libclangCodeGen.so.3.7+0x1a92dc)
#​21 0x7f4f5bae4a2a clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl, llvm::Function*, clang::CodeGen::CGFunctio
nInfo const&) (/opt/clang/lib64/libclangCodeGen.so.3.7+0x1cda2a)
#​22 0x7f4f5baf2733 clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl, llvm::GlobalValue*) (/opt/cl
ang/lib64/libclangCodeGen.so.3.7+0x1db733)
#​23 0x7f4f5baef5c3 clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl, llvm::GlobalValue*) (/opt/clang/lib6
4/libclangCodeGen.so.3.7+0x1d85c3)
#​24 0x7f4f5baf4169 clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) (/opt/clang/lib64/libclangCodeGen.so.3.7+0x1d
d169)
#​25 0x7f4f5bb57acf (/opt/clang/lib64/libclangCodeGen.so.3.7+0x240acf)
#​26 0x7f4f5badf1e7 (/opt/clang/lib64/libclangCodeGen.so.3.7+0x1c81e7)
#​27 0x7f4f5cce7343 clang::ParseAST(clang::Sema&, bool, bool) (/opt/clang/lib64/libclangParse.so.3.7+0x2b343)
#​28 0x7f4f61bd82ce clang::FrontendAction::Execute() (/opt/clang/lib64/libclangFrontend.so.3.7+0xa22ce)
#​29 0x7f4f61baa2cc clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/opt/clang/lib64/libclangFrontend.so.3.7+0x742cc)
#​30 0x7f4f619341ec clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/opt/clang/lib64/libclangFrontendTool.so.3.7+0x31ec)
#​31 0x40f5b1 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/opt/clang/bin/clang-3.7+0x40f5b1)
#​32 0x40e386 main (/opt/clang/bin/clang-3.7+0x40e386)
#​33 0x7f4f610b68c5 __libc_start_main /usr/src/debug/glibc-2.21/csu/libc-start.c:323:0
#​34 0x40b959 _start (/opt/clang/bin/clang-3.7+0x40b959)
Stack dump:
0. Program arguments: /opt/clang/bin/clang-3.7 -cc1 -triple x86_64-suse-linux -emit-obj -disable-free -main-file-name t.cpp -mrelocation-model static -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -momit-leaf-frame-pointer -dwarf-column-info -resource-dir /opt/clang/bin/../lib64/clang/3.7.0 -internal-isystem /opt/clang/bin/../include/c++/v1 -internal-isystem /usr/local/include -internal-isystem /opt/clang/bin/../lib64/clang/3.7.0/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -O2 -fdeprecated-macro -fdebug-compilation-dir /home/ismail -ferror-limit 19 -fmessage-length 126 -fopenmp -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o /tmp/t-c07ad4.o -x c++ t.cpp

  1.  <eof> parser at end of file
    
  2.  t.cpp:5:5: LLVM IR generation of declaration 'main'
    
  3.  t.cpp:5:5: Generating code for declaration 'main'
    

clang-3.7: error: unable to execute command: Aborted
clang-3.7: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 3.7.0 (trunk 238128)
Target: x86_64-suse-linux
Thread model: posix
clang-3.7: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script.
clang-3.7: note: diagnostic msg:


PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-3.7: note: diagnostic msg: /tmp/t-cfa054.cpp
clang-3.7: note: diagnostic msg: /tmp/t-cfa054.sh
clang-3.7: note: diagnostic msg:


@ismail
Copy link
Contributor Author

ismail commented May 29, 2015

Possibly resolved by Chandler's changes. Works fine with r238544

@ismail
Copy link
Contributor Author

ismail commented May 29, 2015

Ok reopen was testing a wrong build.

@ismail
Copy link
Contributor Author

ismail commented Jun 1, 2015

Compile time crash seems to be resolved but now the resulting executable crashes, how to reproduce:

  1. Download http://www.kevinbeason.com/smallpt/smallpt.txt and rename to smallpt.cpp

  2. clang++ -Wno-c++11-narrowing -fopenmp smallpt.cpp

  3. Make sure its linked to right omp library:

λ ldd a.out
linux-vdso.so.1 (0x00007ffdb81c0000)
libc++.so.1 => /opt/clang/lib64/libc++.so.1 (0x00007f424f803000)
libc++abi.so.1 => /opt/clang/lib64/libc++abi.so.1 (0x00007f424f5c0000)
libm.so.6 => /lib64/libm.so.6 (0x00007f424f2be000)
libomp.so => /opt/clang/lib64/libomp.so (0x00007f424efef000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f424edd8000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f424ebba000)
libc.so.6 => /lib64/libc.so.6 (0x00007f424e81a000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f424e616000)
/lib64/ld-linux-x86-64.so.2 (0x00007f424fab9000)

  1. Run the executable with 100 as input:

λ ./a.out 100
Rendering (100 spp) 37.29%zsh: segmentation fault ./a.out 100

Looking under gdb the backtrace looks like an infinite recursion:

[...]
#​2065 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2066 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2067 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2068 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2069 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2070 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2071 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2072 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2073 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2074 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2075 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2076 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2077 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2078 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2079 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2080 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2081 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2082 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2083 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2084 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2085 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2086 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2087 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2088 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2089 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2090 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2091 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2092 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2093 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2094 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2095 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2096 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2097 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2098 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2099 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2100 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2101 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2102 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2103 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2104 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2105 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2106 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2107 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2108 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2109 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2110 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2111 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2112 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2113 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2114 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2115 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2116 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2117 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2118 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2119 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2120 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2121 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2122 0x000000000040210c in radiance(Ray const&, int, unsigned short*) ()
#​2123 0x0000000000401d84 in radiance(Ray const&, int, unsigned short*) ()
#​2124 0x0000000000402409 in radiance(Ray const&, int, unsigned short*) ()
#​2125 0x0000000000402515 in radiance(Ray const&, int, unsigned short*) ()
#​2126 0x00000000004025e2 in radiance(Ray const&, int, unsigned short*) ()
#​2127 0x000000000040309e in .omp_outlined. ()
#​2128 0x00007fc026682f03 in __kmp_invoke_microtask () at ../projects/openmp/runtime/src/z_Linux_asm.s:1373
#​2129 0x00007fc02662c706 in __kmp_invoke_task_func (gtid=7) at ../projects/openmp/runtime/src/kmp_runtime.c:6869
#​2130 0x00007fc02662b6a8 in __kmp_launch_thread (this_thr=0x2361880) at ../projects/openmp/runtime/src/kmp_runtime.c:5534
#​2131 0x00007fc02664d7ff in __kmp_launch_worker (thr=0x2361880) at ../projects/openmp/runtime/src/z_Linux_util.c:744
#​2132 0x00007fc0261c3484 in start_thread (arg=0x7fc01effa8c0) at pthread_create.c:333
#​2133 0x00007fc025f01a4d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

@alexey-bataev
Copy link
Member

  1. The first bug is still reproduced, but only at -O1 and higher optimization levels. Will be investigated and fixed.
  2. I could not reproduce a bug in an executable at -O0 and -O2, seems to me you're just running out of stack, try to increase it.

@ismail
Copy link
Contributor Author

ismail commented Jun 11, 2015

  1. The first bug is still reproduced, but only at -O1 and higher
    optimization levels. Will be investigated and fixed.

Thanks.

  1. I could not reproduce a bug in an executable at -O0 and -O2, seems to me
    you're just running out of stack, try to increase it.

I did "ulimit -s unlimited" but the executable still crashes

λ ./a.out 100
Rendering (100 spp) 20.34%[1] 30153 segmentation fault ./a.out 100

@alexey-bataev
Copy link
Member

Fixed in revision 239524.

@ismail
Copy link
Contributor Author

ismail commented Jun 11, 2015

Fixed in revision 239524.

Thanks I'll try to confirm that, meanwhile can you try the run the app with 100 as input? If that works try 5000 ?

gcc works fine with those inputs with 8k stacks.

@alexey-bataev
Copy link
Member

  1. The first bug is still reproduced, but only at -O1 and higher
    optimization levels. Will be investigated and fixed.

Thanks.

It is fixed, try now.

  1. I could not reproduce a bug in an executable at -O0 and -O2, seems to me
    you're just running out of stack, try to increase it.

I did "ulimit -s unlimited" but the executable still crashes

λ ./a.out 100
Rendering (100 spp) 20.34%[1] 30153 segmentation fault ./a.out 100
Hmm, tried your reproducer on MacOS and Linux without any troubles with latest version of libomp. Everything was fine. Try to build new libomp with the latest clang.

@alexey-bataev
Copy link
Member

Fixed in revision 239524.

Thanks I'll try to confirm that, meanwhile can you try the run the app with
100 as input? If that works try 5000 ?

gcc works fine with those inputs with 8k stacks.

Ok, will try

@ismail
Copy link
Contributor Author

ismail commented Jun 11, 2015

  1. The first bug is still reproduced, but only at -O1 and higher
    optimization levels. Will be investigated and fixed.

Thanks.

It is fixed, try now.

  1. I could not reproduce a bug in an executable at -O0 and -O2, seems to me
    you're just running out of stack, try to increase it.

I did "ulimit -s unlimited" but the executable still crashes

λ ./a.out 100
Rendering (100 spp) 20.34%[1] 30153 segmentation fault ./a.out 100
Hmm, tried your reproducer on MacOS and Linux without any troubles with
latest version of libomp. Everything was fine. Try to build new libomp with
the latest clang.

Well I am on very recent (1 day old) llvm/clang/libiomp trunk on Linux x86-64.

@alexey-bataev
Copy link
Member

My results on MacOS

$ ./a.out
Rendering (4 spp) 100.00%
$ ./a.out 100
Rendering (100 spp) 100.00%

Waiting for 5000

@ismail
Copy link
Contributor Author

ismail commented Jun 11, 2015

My results on MacOS

$ ./a.out
Rendering (4 spp) 100.00%
$ ./a.out 100
Rendering (100 spp) 100.00%

Waiting for 5000

Please try on Linux x86-64 just to be sure.

@alexey-bataev
Copy link
Member

On Linux x86_64
$ ./a.out 100
Rendering (100 spp) 100.00%
$ ./a.out 5000
Rendering (5000 spp) 100.00%

@ismail
Copy link
Contributor Author

ismail commented Jun 11, 2015

If I compile with -O2 I can't reproduce the crash either, but at -O0 I can reproduce it.

@ismail
Copy link
Contributor Author

ismail commented Jun 11, 2015

tsan points out some data races inside libiomp:

Atomic read of size 1 at 0x7d680001cd40 by main thread:
#​0 pthread_mutex_lock /home/abuild/rpmbuild/BUILD/llvm/stage2/../projects/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:3194:3 (a.out+0x00000045ffb0)
#​1 void __kmp_resume_template<kmp_flag_64>(int, kmp_flag_64*) /usr/src/debug/llvm/stage2/../projects/openmp/runtime/src/z_Linux_util.c:1842:14 (libomp.so+0x0000000607c7)
#​2 __kmp_resume_64 /usr/src/debug/llvm/stage2/../projects/openmp/runtime/src/z_Linux_util.c:1895 (libomp.so+0x0000000607c7)
#​3 __libc_start_main /usr/src/debug/glibc-2.21/csu/libc-start.c:289 (libc.so.6+0x0000000208c4)

Previous write of size 1 at 0x7d680001cd40 by thread T5:
#​0 pthread_mutex_init /home/abuild/rpmbuild/BUILD/llvm/stage2/../projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:1063:3 (a.out+0x0000004412a0)
#​1 __kmp_suspend_initialize_thread(kmp_info*) /usr/src/debug/llvm/stage2/../projects/openmp/runtime/src/z_Linux_util.c:1659:18 (libomp.so+0x000000062424)

Location is heap block of size 1504 at 0x7d680001c800 allocated by main thread:
#​0 malloc /home/abuild/rpmbuild/BUILD/llvm/stage2/../projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:514:5 (a.out+0x00000043cadd)
#​1 ___kmp_allocate_align(unsigned long, unsigned long, char const*, int) /usr/src/debug/llvm/stage2/../projects/openmp/runtime/src/kmp_alloc.c:1606:31 (libomp.so+0x00000001b6a9)
#​2 __libc_start_main /usr/src/debug/glibc-2.21/csu/libc-start.c:289 (libc.so.6+0x0000000208c4)

Thread T5 (tid=4196, running) created by main thread at:
#​0 pthread_create /home/abuild/rpmbuild/BUILD/llvm/stage2/../projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:849:3 (a.out+0x00000043fc51)
#​1 __kmp_create_worker /usr/src/debug/llvm/stage2/../projects/openmp/runtime/src/z_Linux_util.c:1052:22 (libomp.so+0x00000005cf52)
#​2 __libc_start_main /usr/src/debug/glibc-2.21/csu/libc-start.c:289 (libc.so.6+0x0000000208c4)

SUMMARY: ThreadSanitizer: data race /usr/src/debug/llvm/stage2/../projects/openmp/runtime/src/z_Linux_util.c:1842:14 in void __kmp_resume_template<kmp_flag_64>(int, kmp_flag_64*)

Rendering (100 spp) 0.13%==================
WARNING: ThreadSanitizer: data race (pid=4190)
Atomic read of size 1 at 0x7d680001a940 by thread T5:
#​0 pthread_mutex_lock /home/abuild/rpmbuild/BUILD/llvm/stage2/../projects/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:3194:3 (a.out+0x00000045ffb0)
#​1 void __kmp_resume_template<kmp_flag_64>(int, kmp_flag_64*) /usr/src/debug/llvm/stage2/../projects/openmp/runtime/src/z_Linux_util.c:1842:14 (libomp.so+0x0000000607c7)
#​2 __kmp_resume_64 /usr/src/debug/llvm/stage2/../projects/openmp/runtime/src/z_Linux_util.c:1895 (libomp.so+0x0000000607c7)

Previous write of size 1 at 0x7d680001a940 by thread T8:
#​0 pthread_mutex_init /home/abuild/rpmbuild/BUILD/llvm/stage2/../projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:1063:3 (a.out+0x0000004412a0)
#​1 __kmp_suspend_initialize_thread(kmp_info*) /usr/src/debug/llvm/stage2/../projects/openmp/runtime/src/z_Linux_util.c:1659:18 (libomp.so+0x000000062424)

Location is heap block of size 1504 at 0x7d680001a400 allocated by main thread:
#​0 malloc /home/abuild/rpmbuild/BUILD/llvm/stage2/../projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:514:5 (a.out+0x00000043cadd)
#​1 ___kmp_allocate_align(unsigned long, unsigned long, char const*, int) /usr/src/debug/llvm/stage2/../projects/openmp/runtime/src/kmp_alloc.c:1606:31 (libomp.so+0x00000001b6a9)
#​2 __libc_start_main /usr/src/debug/glibc-2.21/csu/libc-start.c:289 (libc.so.6+0x0000000208c4)

Thread T5 (tid=4196, running) created by main thread at:
#​0 pthread_create /home/abuild/rpmbuild/BUILD/llvm/stage2/../projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:849:3 (a.out+0x00000043fc51)
#​1 __kmp_create_worker /usr/src/debug/llvm/stage2/../projects/openmp/runtime/src/z_Linux_util.c:1052:22 (libomp.so+0x00000005cf52)
#​2 __libc_start_main /usr/src/debug/glibc-2.21/csu/libc-start.c:289 (libc.so.6+0x0000000208c4)

Thread T8 (tid=4199, running) created by main thread at:
#​0 pthread_create /home/abuild/rpmbuild/BUILD/llvm/stage2/../projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:849:3 (a.out+0x00000043fc51)
#​1 __kmp_create_worker /usr/src/debug/llvm/stage2/../projects/openmp/runtime/src/z_Linux_util.c:1052:22 (libomp.so+0x00000005cf52)
#​2 __libc_start_main /usr/src/debug/glibc-2.21/csu/libc-start.c:289 (libc.so.6+0x0000000208c4)

SUMMARY: ThreadSanitizer: data race /usr/src/debug/llvm/stage2/../projects/openmp/runtime/src/z_Linux_util.c:1842:14 in void __kmp_resume_template<kmp_flag_64>(int, kmp_flag_64*)

@alexey-bataev
Copy link
Member

I think it's better to report this problem to openmp-dev mailing list directly.

@ismail
Copy link
Contributor Author

ismail commented Jun 15, 2015

Since original bug is fixed, I am closing this bug as fixed. Thank you!

For the other crash I'll send an email to openmp-dev.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 10, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla clang Clang issues not falling into any other category
Projects
None yet
Development

No branches or pull requests

2 participants