cmssw: Segfault on file close in materialBudgetTrackerPlots test
The test failing in https://cmssdt.cern.ch/SDT/cgi-bin/logreader/cc8_aarch64_gcc8/CMSSW_11_2_X_2020-07-20-2300/unitTestLogs/Validation/Geometry#/ and https://cmssdt.cern.ch/SDT/cgi-bin/logreader/slc7_aarch64_gcc820/CMSSW_11_2_X_2020-07-20-2300/unitTestLogs/Validation/Geometry#/
has the following log:
21-Jul-2020 21:00:01 CEST Closed file file:single_neutrino_random.root
A fatal system signal has occurred: segmentation violation
The following is the call stack containing the origin of the signal.
Tue Jul 21 21:00:07 CEST 2020
Thread 257 (Thread 0xfffc3abaf200 (LWP 49931)):
#0 0x0000ffff9f13a9c4 in nanosleep () from /lib64/libc.so.6
#1 0x0000ffff9f13a678 in sleep () from /lib64/libc.so.6
#2 0x0000ffff907768d8 in sig_pause_for_stacktrace () from /cvmfs/cms-ib.cern.ch/week0/slc7_aarch64_gcc820/cms/cmssw/CMSSW_11_2_X_2020-07-20-2300/lib/slc7$
#3 <signal handler called>
#4 0x0000ffff9f16a6e4 in syscall () from /lib64/libc.so.6
#5 0x0000ffff9c6b40e8 in tbb::internal::futex_wait (comparand=2, futex=0xffff8e8a852c) at ../../include/tbb/machine/linux_common.h:81
#6 tbb::internal::binary_semaphore::P (this=0xffff8e8a852c) at ../../src/tbb/semaphore.h:205
#7 rml::internal::thread_monitor::commit_wait (c=..., this=0xffff8e8a8520) at ../../src/tbb/../rml/server/thread_monitor.h:255
#8 tbb::internal::rml::private_worker::run (this=0xffff8e8a8500) at ../../src/tbb/private_server.cpp:273
#9 0x0000ffff9c6b410c in tbb::internal::rml::private_worker::thread_routine (arg=<optimized out>) at ../../src/tbb/private_server.cpp:219
#10 0x0000ffff9f347d38 in start_thread () from /lib64/libpthread.so.0
#11 0x0000ffff9f16f5f0 in thread_start () from /lib64/libc.so.6
Thread 256 (Thread 0xfffc3afbf200 (LWP 49930)):
#0 0x0000ffff9f13a9c4 in nanosleep () from /lib64/libc.so.6
#1 0x0000ffff9f13a678 in sleep () from /lib64/libc.so.6
#2 0x0000ffff907768d8 in sig_pause_for_stacktrace () from /cvmfs/cms-ib.cern.ch/week0/slc7_aarch64_gcc820/cms/cmssw/CMSSW_11_2_X_2020-07-20-2300/lib/slc7$
#3 <signal handler called>
#4 0x0000ffff9f16a6e4 in syscall () from /lib64/libc.so.6
#5 0x0000ffff9c6b40e8 in tbb::internal::futex_wait (comparand=2, futex=0xffff8e8a842c) at ../../include/tbb/machine/linux_common.h:81
#6 tbb::internal::binary_semaphore::P (this=0xffff8e8a842c) at ../../src/tbb/semaphore.h:205
#7 rml::internal::thread_monitor::commit_wait (c=..., this=0xffff8e8a8420) at ../../src/tbb/../rml/server/thread_monitor.h:255
#8 tbb::internal::rml::private_worker::run (this=0xffff8e8a8400) at ../../src/tbb/private_server.cpp:273
#9 0x0000ffff9c6b410c in tbb::internal::rml::private_worker::thread_routine (arg=<optimized out>) at ../../src/tbb/private_server.cpp:219
#10 0x0000ffff9f347d38 in start_thread () from /lib64/libpthread.so.0
#11 0x0000ffff9f16f5f0 in thread_start () from /lib64/libc.so.6
It’s very consistent in the tests but not when ran by hand.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 24 (24 by maintainers)
I just took a look and for the python module CmsRun I failed to update it to match a change I made a while ago where I moved the setting of the number of TBB threads. So right now CmsRun will use TBB’s default (not cmsRun’s default) which is to use all threads. I will work on a fix.