Segmentation Fault caused by parallel_for

[Johannes_J_]

Hello,

I used TBB for a few years now. Today I found that my application crashes. This is code that worked before, and for quite a while so. I found that it doesn't really matter what my parallel task is doing and even the following code leads to a segmentation fault:

	tbb::parallel_for(tbb::blocked_range2d<int>(0, 255, // row range

	                                            0, 255), // column range

	                  [&](const tbb::blocked_range2d<int> &r) {

		return;

	});

(Note that passing 0, 0, 0, 0 to the range does not segfault)

This is  my GDB output:

Thread 17 "CommandRunner" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff91d5a700 (LWP 16343)]
0x00007ffff6168262 in ?? () from /usr/lib/libtbb.so.2
(gdb) bt
#0  0x00007ffff6168262 in ?? () from /usr/lib/libtbb.so.2
#1  0x00007ffff616832b in ?? () from /usr/lib/libtbb.so.2
#2  0x00007ffff6169e28 in ?? () from /usr/lib/libtbb.so.2
#3  0x00007ffff6168c22 in ?? () from /usr/lib/libtbb.so.2
#4  0x00007ffff6163510 in ?? () from /usr/lib/libtbb.so.2
#5  0x00007ffff6161725 in tbb::internal::allocate_root_with_context_proxy::allocate(unsigned long) const () from /usr/lib/libtbb.so.2
#6  0x000000000056f17f in operator new (p=..., bytes=64) at /usr/include/tbb/task.h:1005
#7  tbb::interface9::internal::start_for<tbb::blocked_range2d<int, int>, rgb::RGBDisplay::execute(std::map<std::__cxx11::basic_string<char>, boost::any>&, ProgressObserver*)::<lambda(const tbb::blocked_range2d<int, int>&)>, const tbb::auto_partitioner>::run (body=..., partitioner=..., range=...)
    at /usr/include/tbb/parallel_for.h:88
#8  tbb::parallel_for<tbb::blocked_range2d<int>, rgb::RGBDisplay::execute(std::map<std::__cxx11::basic_string<char>, boost::any>&, ProgressObserver*)::<lambda(const tbb::blocked_range2d<int>&)> > (body=..., range=...) at /usr/include/tbb/parallel_for.h:186
#9  rgb::RGBDisplay::execute (this=0x9be010, input=std::map with 1 elements = {...}, po=0x33d1020) at ../rgb/rgb.cpp:70

The same thing in Valgrind:

==16218== Thread 17 CommandRunner:
==16218== Invalid read of size 8
==16218==    at 0x68B0262: ??? (in /usr/lib/libtbb.so.2)
==16218==    by 0x68B032A: ??? (in /usr/lib/libtbb.so.2)
==16218==    by 0x68B1E27: ??? (in /usr/lib/libtbb.so.2)
==16218==    by 0x68B0C21: ??? (in /usr/lib/libtbb.so.2)
==16218==    by 0x68AB50F: ??? (in /usr/lib/libtbb.so.2)
==16218==    by 0x68A9724: tbb::internal::allocate_root_with_context_proxy::allocate(unsigned long) const (in /usr/lib/libtbb.so.2)
==16218==    by 0x583FBE: rgb::RGBDisplay::execute(std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::any, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, boost::any> > >&, ProgressObserver*) (in /home/ypnos/work/gerbil/master/build-release/bin/qgerbil)

Now I do have TBB calls in other threads that work, and it seems that this is related to from which thread parallel_for() is called. I did not have any task scheduler init before, so I added the object in the beginning of my main() so that it is there, and stays. Is there anything else that I might be missing?

TBB 4.4_20160413-1
gcc version 6.1.1 20160501 (GCC)
Linux 4.5.4-1-ARCH

Best,
Johannes

[Alexei_K_Intel]

Hello,

Could you add "TBB_VERSION=1" to the environment and run the application to get additional version information from libtbb.so.2? Could you also rebuild the application with the debug version of the TBB library: libtbb_debug.so.2?

Thank you in advance.

Regards, Alex.

[Johannes_J_]

Output of TBB_VERSION=1:

TBBmalloc: VERSION        4.4
TBBmalloc: INTERFACE VERSION    9004
TBBmalloc: BUILD_DATE        Wed May 18 07:07:55 UTC 2016
TBBmalloc: BUILD_HOST         (x86_64)
TBBmalloc: BUILD_OS        Arch Linux r (l)
TBBmalloc: BUILD_KERNEL    Linux 4.5.1-1-ARCH #1 SMP PREEMPT Thu Apr 14 19:19:32 CEST 2016
TBBmalloc: BUILD_GCC        g++ (GCC) 6.1.1 20160501
TBBmalloc: BUILD_LIBC    2.23
TBBmalloc: BUILD_LD
TBBmalloc: BUILD_TARGET    intel64 on cc6.1.1_libc2.23_kernel4.5.1
TBBmalloc: BUILD_COMMAND    g++ -DDO_ITT_NOTIFY -g -O2 -DUSE_PTHREAD -m64 -mrtm -fPIC -D__TBB_BUILD=1
 -Wall -Wno-parentheses -Wno-non-virtual-dtor -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-st
rong -I../../src -I../../src/rml/include -I../../include -I.
TBBmalloc: TBB_USE_DEBUG    0
TBBmalloc: TBB_USE_ASSERT    0
TBBmalloc: DO_ITT_NOTIFY    1
TBBmalloc: huge pages    not requested
TBB: VERSION        4.4
TBB: INTERFACE VERSION    9004
TBB: BUILD_DATE        Wed May 18 07:07:55 UTC 2016
TBB: BUILD_HOST         (x86_64)
TBB: BUILD_OS        Arch Linux r (l)
TBB: BUILD_KERNEL    Linux 4.5.1-1-ARCH #1 SMP PREEMPT Thu Apr 14 19:19:32 CEST 2016
TBB: BUILD_GCC        g++ (GCC) 6.1.1 20160501
TBB: BUILD_LIBC    2.23
TBB: BUILD_LD
TBB: BUILD_TARGET    intel64 on cc6.1.1_libc2.23_kernel4.5.1
TBB: BUILD_COMMAND    g++ -DDO_ITT_NOTIFY -g -O2 -DUSE_PTHREAD -m64 -mrtm -fPIC -D__TBB_BUILD=1 -Wall -
Wno-parentheses -Wno-non-virtual-dtor -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -I.
./../src -I../../src/rml/include -I../../include -I.
TBB: TBB_USE_DEBUG    0
TBB: TBB_USE_ASSERT    0
TBB: DO_ITT_NOTIFY    1
TBB: RML    private
TBB: Tools support    disabled
NVIDIA: no NVIDIA devices found

With libtbb_debug.so.2, the segmentation fault does not occur. I forgot to mention that. I had to do a Release with Debug symbols build to produce the output in my first posting.

Thank you for your help,

Johannes

[Alexei_K_Intel · Accepted solution]

Hi Johannes,

Could you consider the post (https://software.intel.com/en-us/forums/intel-threading-building-blocks/topic/641654)? It looks relevant to the issue that you observe. Perhaps, you want to try a suggested work-around to compile TBB with one of the switches "-fno-builtin-memset (will force GCC not to optimise away memset), -flifetime-dse=1 or -fno-lifetime-dse."

[Johannes_J_]

Thank you for your suggestion. Adding -flifetime-dse=1 indeed solves the problem. I hope this can be fixed in TBB soon, as I cannot control how TBB is compiled for the users of my software.