Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Leonard_K_
Beginner
285 Views

after-build tests partially fail

Jump to solution

Two after-build tests fail for the intel TBB source:

make rml (which by default also makes rml_test - which fails):

./test_rml_mixed.exe 
Assertion my_make_server_routine failed on line 86 of file ../../src/rml/client/rml_factory.h
../../build/Makefile.rml:150: recipe for target 'rml_test' failed
make[1]: *** [rml_test] Aborted (core dumped)
make[1]: Leaving directory '/path_to_src_dir/tbb43_VERSIONoss/build/linux_intel64_gcc_cc5.2.0_libc2.22_kernel4.2.0_debug'
Makefile:50: recipe for target 'rml' failed
make: *** [rml] Error 2

VERSION is confirmed to atleast be either 20150611 or 20150728.

Also the make-target `test` fails, at some point:

TBB Warning: RML might limit the number of workers to 7 while 15 is requested.

Call stack info (6):
./test_tbb_fork.exe(_Z16print_call_stackv+0x44)[0x4045ba]
./test_tbb_fork.exe(_Z11ReportErrorPKciS0_S0_+0x1d)[0x4046a3]
./test_tbb_fork.exe(_Z8TestMainv+0x377)[0x404f45]
./test_tbb_fork.exe(main+0x2d)[0x404a1a]
/usr/lib/libc.so.6(__libc_start_main+0xf0)[0x7f976d601610]
./test_tbb_fork.exe(_start+0x29)[0x4044a9]
../../src/test/test_tbb_fork.cpp:195, assertion 0: Hang after fork
../../build/Makefile.test:251: recipe for target 'test_tbb_plain' failed
make[1]: *** [test_tbb_plain] Aborted (core dumped)
make[1]: Leaving directory '/path_to_src_dir/tbb43_VERSIONoss/build/linux_intel64_gcc_cc5.2.0_libc2.22_kernel4.1.8_debug'
Makefile:44: recipe for target 'test' failed
make: [test] Error 2 (ignored)

The error in the `rml` target is that the assertion failed that 'factory' could not be opened - at least that's the comment above the critical line:

Assertion my_make_server_routine failed on line 86 of file ../../src/rml/client/rml_factory.h

Same thing for the VERSION.

I could not check why both assertions fail (first: fail to open `factory`; second: thread hangs even after pkill and reaches code that shouldn't be reached). The issue not only exists on GCC5 but I also tested it on GCC4.9.

Any idea why the tests fail? Bug in the source or libraries?

 

Other links: https://bugs.archlinux.org/task/46160

0 Kudos
1 Solution
285 Views
This is *not* the rml I'm just running 'make && make test'. Could you please double-check this? I.e., TBB_VERSION=1 LD_LIBRARY_PATH=. ./test_tbb_fork.exe 2>&1|grep RML returns TBB: RML shared when shared RML is in use, and TBB: RML private when no shared RML found.

View solution in original post

8 Replies
285 Views

Hello larkey,

1. Shared RML is not documented and I do not recomend to use it and especially to include it to the package. Private RML is located inside tbb libraries.
2. fork() stuff is more interesting, do you have any fork limitations on your system? this is a simple fork() test so it should work pretty stable on systems where fork works well.

UPD for fork(): this test does not work with shared RML. 

--Vladimir

Leonard_K_
Beginner
285 Views

Vladimir Polin (Intel) wrote:

Hello larkey,

1. Shared RML is not documented and I do not recomend to use it and especially to include it to the package. Private RML is located inside tbb libraries.

Oh, well, I came across it since I found quite some packages that wanted to load libirml.so but couldn't due to it missing (namely unity-editor, the Linux-Build for the unity3d engine).

So I did some research and ended up building it via these sources. Are they supposed to ship the binary library when distributing the engine?


2. fork() stuff is more interesting, do you have any fork limitations on your system? this is a simple fork() test so it should work pretty stable on systems where fork works well.

UPD for fork(): this test does not work with shared RML. 

--Vladimir

Not as far as I know I have any fork() limitations. The specific problem seems to be that the forked process gets killed but still continues to run (for some time - at least as long as it needs to reach the test).

If you need more information I could provide, feel free to ask and thank you for the clarifications on RML.

285 Views

larkey wrote:

So I did some research and ended up building it via these sources. Are they supposed to ship the binary library when distributing the engine?

No, this library is not needed for unity editor.

larkey wrote:

If you need more information I could provide, feel free to ask and thank you for the clarifications on RML.

Like I wrote before fork() unit test does not work with shared RML. So no information is needed.

-- thanks, Vladimir

Leonard_K_
Beginner
285 Views

Vladimir Polin (Intel) wrote:

Quote:

larkey wrote:

 

So I did some research and ended up building it via these sources. Are they supposed to ship the binary library when distributing the engine?

 

 

No, this library is not needed for unity editor.

I ran ldd on the Unity editor binary and it did search for it.

Quote:

larkey wrote:

 

If you need more information I could provide, feel free to ask and thank you for the clarifications on RML.

 

 

Like I wrote before fork() unit test does not work with shared RML. So no information is needed.

Well, you before said:

2. fork() stuff is more interesting, do you have any fork limitations on your system? this is a simple fork() test so it should work pretty stable on systems where fork works well.

This is *not* the rml I'm just running 'make && make test'.

286 Views
This is *not* the rml I'm just running 'make && make test'. Could you please double-check this? I.e., TBB_VERSION=1 LD_LIBRARY_PATH=. ./test_tbb_fork.exe 2>&1|grep RML returns TBB: RML shared when shared RML is in use, and TBB: RML private when no shared RML found.

View solution in original post

Leonard_K_
Beginner
285 Views

Alexandr Konovalov (Intel) wrote:

This is *not* the rml I'm just running 'make && make test'.

Could you please double-check this? I.e.,

TBB_VERSION=1 LD_LIBRARY_PATH=. ./test_tbb_fork.exe 2>&1|grep RML

returns

TBB: RML shared

when shared RML is in use, and

TBB: RML private

when no shared RML found.

 

Ah, so because I've built RML before, it automatically loaded the shared RML and thus failed. I thought I had to explicitly tell it to use the shared lib.

So this seems to work now and shared RML should not be built using these sources. Still weird though that Unity wants to link against RML:

LD_DEBUG on unity-editor binary:

26751:	find library=libirml.so.1 [0]; searching
26751:	search path=/opt/Unity/Editor/Data/Tools:/opt/Unity/Editor	(RPATH from file ./Unity)
26751:	trying file=/opt/Unity/Editor/Data/Tools/libirml.so.1
26751:	trying file=/opt/Unity/Editor/libirml.so.1
26751:	search cache=/etc/ld.so.cache
26751:	search path=/usr/lib/tls/x86_64:/usr/lib/tls:/usr/lib/x86_64:/usr/lib	(system search path)
26751:	trying file=/usr/lib/tls/x86_64/libirml.so.1
26751:	trying file=/usr/lib/tls/libirml.so.1
26751:	trying file=/usr/lib/x86_64/libirml.so.1
26751:	trying file=/usr/lib/libirml.so.1

 

Well, this seems to be a Unity-issue then - as long as there are no other sources we should build the shared lib from, am I correct?

RafSchietekat
Black Belt
285 Views

Could "make rml" be made to "just work", though? With TBB 4.4 on OS X 10.10.5 and command-line tools from Xcode 7.0 (both nearly up-to-date), I get:

./test_rml_tbb.exe 
Call stack info (6):
0   test_rml_tbb.exe                    0x00000001009612be _Z16print_call_stackv + 94
1   test_rml_tbb.exe                    0x000000010096140c _Z11ReportErrorPKciS0_S0_ + 28
2   test_rml_tbb.exe                    0x0000000100962cdd _Z20VerifyInitializationIN3tbb8internal3rml11tbb_factoryE8MyClientEvi + 205
3   test_rml_tbb.exe                    0x0000000100961913 _Z8TestMainv + 19
4   test_rml_tbb.exe                    0x00000001009615ce main + 46
5   libdyld.dylib                       0x00007fff84c735c9 start + 1
../../src/rml/test/test_server.h:409, assertion status!=Factory::st_not_found: could not find RML library
make[1]: *** [rml_test] Abort trap: 6
make: *** [rml] Error 2

 

Leonard_K_
Beginner
285 Views

Raf Schietekat wrote:

Could "make rml" be made to "just work", though? With TBB 4.4 on OS X 10.10.5 and command-line tools from Xcode 7.0 (both nearly up-to-date), I get:

Well, I think it could but it's quite unsure it's stable. And if I understood them correctly we are not supposed to use it but people who need it just ship the lib with the program.

Reply