Intel® Integrated Performance Primitives
Deliberate problems developing high-performance vision, signal, security, and storage applications.
6709 Discussions

libiomp5.so:__kcmp_query_cpuid() hangs in strrchr()

clemtaylor
Beginner
‎07-30-2009 12:03 PM
545 Views
I just installed IPP 6.1.1.042 and ICC 11.1.046 on a new Fedora 11 x86_64 system. The ipp-samples/audio-video-codes compiled just fine, but when I run umc_video_enc_con it consumes 100% cpu and seems to be stuck inside of strrchr(), called from __kmp_query_cpuid().

gdb shows:
[shell]#0  0x0000000000417f30 in strrchr ()
#1  0x00007ffff7178142 in __kmp_query_cpuid ()
   from /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libiomp5.so
#2  0x00007ffff7166b73 in __kmp_init_lock ()
   from /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libiomp5.so
#3  0x00007ffff7172612 in ?? ()
   from /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libiomp5.so
#4  0x00007ffff716f547 in __kmp_serial_initialize ()
   from /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libiomp5.so
#5  0x00007ffff7161f2e in omp_get_num_procs ()
   from /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libiomp5.so
#6  0x00007ffff729ff3d in _init ()
   from /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libippcoreem64t.so.6.1
#7  0x0000003e0c80ea69 in call_init (l=0x7ffff73a9000, argc=1, 
    argv=0x7fffffffe418, env=0x7fffffffe428) at dl-init.c:70
#8  0x0000003e0c80ebef in _dl_init (main_map=0x7ffff7ffd000, argc=1, 
    argv=0x7fffffffe418, env=0x7fffffffe428) at dl-init.c:134
#9  0x0000003e0c800b2a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2

ldd shows:[/shell]
[shell] $ ldd umc_video_enc_con 
	linux-vdso.so.1 =>  (0x00007fff39dff000)
	libippdcem64t.so.6.1 => /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libippdcem64t.so.6.1 (0x00007f1d4a31c000)
	libippccem64t.so.6.1 => /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libippccem64t.so.6.1 (0x00007f1d4a1fb000)
	libippacem64t.so.6.1 => /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libippacem64t.so.6.1 (0x00007f1d4a0ec000)
	libippsrem64t.so.6.1 => /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libippsrem64t.so.6.1 (0x00007f1d49fc3000)
	libippvcem64t.so.6.1 => /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libippvcem64t.so.6.1 (0x00007f1d49ea1000)
	libippcvem64t.so.6.1 => /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libippcvem64t.so.6.1 (0x00007f1d49d78000)
	libippjem64t.so.6.1 => /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libippjem64t.so.6.1 (0x00007f1d49c66000)
	libippiem64t.so.6.1 => /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libippiem64t.so.6.1 (0x00007f1d49a9a000)
	libippsem64t.so.6.1 => /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libippsem64t.so.6.1 (0x00007f1d49921000)
	libippscem64t.so.6.1 => /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libippscem64t.so.6.1 (0x00007f1d49804000)
	libippcoreem64t.so.6.1 => /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libippcoreem64t.so.6.1 (0x00007f1d496f4000)
	libdl.so.2 => /lib64/libdl.so.2 (0x0000003e0d600000)
	libiomp5.so => /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libiomp5.so (0x00007f1d49587000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003e0da00000)
	libm.so.6 => /lib64/libm.so.6 (0x0000003e0d200000)
	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003e14a00000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003e12a00000)
	libc.so.6 => /lib64/libc.so.6 (0x0000003e0ce00000)
	/lib64/ld-linux-x86-64.so.2 (0x0000003e0c800000)
[/shell]
Any ideas what might be going on? Querying the cpuid seems to be a pretty basic operation. The same thing happens with simple_player and umc_h264_dec_con. The system is a dual socket E5520 based running 2.6.30.3.

I recompiled with gcc 4.4.0, h264_enc failed to compile, but simple_player & umc_h264_dec_con compiled and doesn't get stuck in __kmp_query_cpuid().

Thanks,
Clem
0 Kudos

Link Copied

6 Replies
Ying_H_Intel
Employee
‎08-02-2009 11:27 PM
545 Views
Quoting - clemtaylor
I just installed IPP 6.1.1.042 and ICC 11.1.046 on a new Fedora 11 x86_64 system. The ipp-samples/audio-video-codes compiled just fine, but when I run umc_video_enc_con it consumes 100% cpu and seems to be stuck inside of strrchr(), called from __kmp_query_cpuid().

gdb shows:
[shell]#0  0x0000000000417f30 in strrchr ()
#1  0x00007ffff7178142 in __kmp_query_cpuid ()
   from /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libiomp5.so
#2  0x00007ffff7166b73 in __kmp_init_lock ()
   from /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libiomp5.so
#3  0x00007ffff7172612 in ?? ()
   from /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libiomp5.so
#4  0x00007ffff716f547 in __kmp_serial_initialize ()
   from /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libiomp5.so
#5  0x00007ffff7161f2e in omp_get_num_procs ()
   from /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libiomp5.so
#6  0x00007ffff729ff3d in _init ()
   from /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libippcoreem64t.so.6.1
#7  0x0000003e0c80ea69 in call_init (l=0x7ffff73a9000, argc=1, 
    argv=0x7fffffffe418, env=0x7fffffffe428) at dl-init.c:70
#8  0x0000003e0c80ebef in _dl_init (main_map=0x7ffff7ffd000, argc=1, 
    argv=0x7fffffffe418, env=0x7fffffffe428) at dl-init.c:134
#9  0x0000003e0c800b2a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2

ldd shows:[/shell]
[shell] $ ldd umc_video_enc_con 
	linux-vdso.so.1 =>  (0x00007fff39dff000)
	libippdcem64t.so.6.1 => /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libippdcem64t.so.6.1 (0x00007f1d4a31c000)
	libippccem64t.so.6.1 => /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libippccem64t.so.6.1 (0x00007f1d4a1fb000)
	libippacem64t.so.6.1 => /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libippacem64t.so.6.1 (0x00007f1d4a0ec000)
	libippsrem64t.so.6.1 => /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libippsrem64t.so.6.1 (0x00007f1d49fc3000)
	libippvcem64t.so.6.1 => /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libippvcem64t.so.6.1 (0x00007f1d49ea1000)
	libippcvem64t.so.6.1 => /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libippcvem64t.so.6.1 (0x00007f1d49d78000)
	libippjem64t.so.6.1 => /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libippjem64t.so.6.1 (0x00007f1d49c66000)
	libippiem64t.so.6.1 => /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libippiem64t.so.6.1 (0x00007f1d49a9a000)
	libippsem64t.so.6.1 => /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libippsem64t.so.6.1 (0x00007f1d49921000)
	libippscem64t.so.6.1 => /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libippscem64t.so.6.1 (0x00007f1d49804000)
	libippcoreem64t.so.6.1 => /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libippcoreem64t.so.6.1 (0x00007f1d496f4000)
	libdl.so.2 => /lib64/libdl.so.2 (0x0000003e0d600000)
	libiomp5.so => /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libiomp5.so (0x00007f1d49587000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003e0da00000)
	libm.so.6 => /lib64/libm.so.6 (0x0000003e0d200000)
	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003e14a00000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003e12a00000)
	libc.so.6 => /lib64/libc.so.6 (0x0000003e0ce00000)
	/lib64/ld-linux-x86-64.so.2 (0x0000003e0c800000)
[/shell]
Any ideas what might be going on? Querying the cpuid seems to be a pretty basic operation. The same thing happens with simple_player and umc_h264_dec_con. The system is a dual socket E5520 based running 2.6.30.3.

I recompiled with gcc 4.4.0, h264_enc failed to compile, but simple_player & umc_h264_dec_con compiled and doesn't get stuck in __kmp_query_cpuid().

Thanks,
Clem

Hello Clem,

Could you please attach(or copy)some build log file, which is in _log directory,for example, h264_enc.log and see which cause the compile error?

The sample is threaded by OpenMP library libiomp5, which provide by intel Compiler. It will be switch onwhen Intel Compiler are used. culd you tell methe build command line when you build the ipp-sample/audio-video-codec/sample with icc and gcc4 seperately?

for example ,I have Intel compiler 11.0.083 installed and run the command line
>buildem64t.sh

Then check the log file,we will see

/opt/intel/Compiler/11.0/083/bin/intel64/icpc -Wall -O2 -fPIC -fopenmp -I/opt/intel/ipp/6.0.0.063/em64t/include -I./include -I./../../application/umc_video_enc_con/include -I./../../codec/aac_dec/include -I./../../codec/aac_dec_int/include

icpc: command line warning #10006: ignoring unknown option '-fopenmp'

Here the -fopenmp is the option for gcc latest version (which support OpenMP threading), itis not rightcompile option in icc.Could you please change the -fopenmp into -openmp in Makefile, then rebuild again and see if there is any change?

Regards,
Ying
0 Kudos
Copy link
clemtaylor
Beginner
‎08-03-2009 12:00 PM
545 Views
Quoting - Ying Hu (Intel)
Could you please attach(or copy)some build log file, which is in _log directory,for example, h264_enc.log and see which cause the compile error?

The sample is threaded by OpenMP library libiomp5, which provide by intel Compiler. It will be switch onwhen Intel Compiler are used. culd you tell methe build command line when you build the ipp-sample/audio-video-codec/sample with icc and gcc4 seperately?

Okay, changing the makefile to pass -openmp to icc results in a loader (I'd assume) warning message when I start umc_video_enc_con (same warning printed by ldd) and then it hangs in the same place.

_bin/linuxem64t_icc111/umc_video_enc_con: /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libiomp5.so: no version information available (required by _bin/linuxem64t_icc111/umc_video_enc_con)

With gcc 4.4.0, h264_enc fails to compile with an series of empty #elif errors. I more interested in using IPP with Intel's compiler, so I didn't bother trying to address this.

Any ideas what might be happening with icc?
h264_enc_gcc440.log
umc_video_enc_con.log
0 Kudos
Copy link
Ying_H_Intel
Employee
‎08-05-2009 02:32 AM
545 Views
Quoting - clemtaylor

Okay, changing the makefile to pass -openmp to icc results in a loader (I'd assume) warning message when I start umc_video_enc_con (same warning printed by ldd) and then it hangs in the same place.

_bin/linuxem64t_icc111/umc_video_enc_con: /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libiomp5.so: no version information available (required by _bin/linuxem64t_icc111/umc_video_enc_con)

With gcc 4.4.0, h264_enc fails to compile with an series of empty #elif errors. I more interested in using IPP with Intel's compiler, so I didn't bother trying to address this.

Any ideas what might be happening with icc?

Hello Clemtaylor,

I received the log file. Thanks you.
It looks bothof the issueare related to the new OS:the new Fedora 11 and the new gcc.

1) About the libiomp5.so hang,I willlook into it in detial.
It is threading libraryprovide Intel Compiler,not sure if the libraryis compatiable with such new OS. I will invite Intel Compiler experts to see what's the probelm.
For workaround, would you please try todisable the openmpwhen build the sample?
for example try the command, >export OPENMP_SUPPORT=NO
>export LINKAGE=static
>buildem64t.sh icc11


2) Regarding the error when build with GCC 4.4.
./include/umc_h264_deblocking_tmpl.h:24:16: error: #elif with no expression

Accordign tohttp://gcc.gnu.org/gcc-4.4/porting_to.html, it should be causedby the changewhen upgrade to new GCC 4.4 .

To fix this, either use #else without an argument or provide a constant expression when using #elif.

Or do you have other test machine which haveprevious OS and GCCversion, for example, FC 10, with GCC 4.1? (They should be able to work).

Regards,
Ying

0 Kudos
Copy link
clemtaylor
Beginner
‎08-05-2009 02:42 PM
545 Views
Quoting - Ying Hu (Intel)
1) About the libiomp5.so hang,I willlook into it in detial.
It is threading libraryprovide Intel Compiler,not sure if the libraryis compatiable with such new OS. I will invite Intel Compiler experts to see what's the probelm.
For workaround, would you please try todisable the openmpwhen build the sample?
for example try the command, >export OPENMP_SUPPORT=NO
>export LINKAGE=static
>buildem64t.sh icc11

That is curious. I recompiled without openmp and (mostly) static linkage and it still fails in strrchr(), but from a different path.
[plain](gdb) where
#0  0x0000000000419ba0 in strrchr ()
#1  0x00000000005e73e3 in vm_sys_info_get_program_name ()
#2  0x00000000005e595e in UMC::SysInfo::SysInfo(char*) ()
#3  0x0000000000416947 in main ()

ldd umc_video_enc_con
	linux-vdso.so.1 =>  (0x00007fff33302000)
	libdl.so.2 => /lib64/libdl.so.2 (0x0000003e0d600000)
	libiomp5.so => /opt/intel/ipp/6.1.1.042/em64t/sharedlib/libiomp5.so (0x00007f896ed41000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003e0da00000)
	libm.so.6 => /lib64/libm.so.6 (0x0000003e0d200000)
	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003e14a00000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003e12a00000)
	libc.so.6 => /lib64/libc.so.6 (0x0000003e0ce00000)
	/lib64/ld-linux-x86-64.so.2 (0x0000003e0c800000)
[/plain]
It still seems to depend on libiomp. The simple_player and umc_h264_dec_con will now run without triggering this error.

To get gcc4.4 to compile the h264 encoder I changed all the ':#elif //PIXBITS' to '#else //PIXBITS'. The gcc4.4 compiled binary seems to run (prints usage) but I still haven't tried to encode some video with it yet...

0 Kudos
Copy link
Ying_H_Intel
Employee
‎08-10-2009 01:58 AM
545 Views

Dear Clemtaylor,

Thank you a lot for the GCC4 report.

Regarding libiomp5 still in link, for disablingit youmayneed to modify Makefile and buildxx.sh together:
for example,
In buildem64.sh, below the line 27
. ${SAMPLE_ROOTS}/tools/env/envem64t.sh
add the below three line

OPENMP_SUPPORT="NO"
LINKAGE="static"
LIBPTHREAD="-lpthread"

In makefile, line 175
change
#SYSLIB = -ldl $(ADD_SYSLIB_$(ARCH)) $(LIBPTHREAD)

to
SYSLIB = -ldl -lSDL $(LIBPTHREAD)

All my best,
Ying

0 Kudos
Copy link
Ying_H_Intel
Employee
‎07-15-2010 09:59 PM
545 Views

Hello ~

Just update, the issuehas beenfixed in latest audio_video_codec sample. Get latest sample from http://software.intel.com/en-us/articles/intel-integrated-performance-primitives-code-samples/

Regards,
Ying

0 Kudos
Copy link
Reply

Community support is provided during standard business hours (Monday to Friday 7AM - 5PM PST). Other contact methods are available here.

Intel does not verify all solutions, including but not limited to any file transfers that may appear in this community. Accordingly, Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.

For more complete information about compiler optimizations, see our Optimization Notice.