-ip option

-ip option

Is it OK that the code compiled with -ip option is incompatible with the code compiled without -ip?

26 帖子 / 0 全新
最新文章
如需更全面地了解编译器优化,请参阅优化注意事项

You'd need to be more explicit about what kind of problem you observe, and whether options such as -debug:inline-debug-info or Qip-no-inlining resolve them.

I could imagine that you might require an externally linkable copy of a function which is in-lined, but we'd need more specifics to comment.

In-lining also may expose or hide bugs, for example by offering more opportunities for data over-run to cause problems.  It's intended to facilitate some transformations such as vectorization and elision of parentheses, where -fp:source might be needed to prevent numerical differences.

Hi, Tim!

Ok. Consider an executable A and two shared objects B and C. A is linked with B and loads C via dlopen().

Both B and C instantiate the same template. In my case it was std::map<std::string, unsigned int>. When C is loaded into memory it uses body of instantiated methods located in B. B was compiled with -ip and C was compiled without it. When C issued an insertion to the map via operator[], my program segfaults in some cases. It may segfault or may continue to work, but valgrind in both cases shows a problem in _M_insert_unique method - something like condition or move is based on uninitialized value. When I compiled C with -ip option, the problem disappeared.

I use the latest Intel C++ 2013 SP1 Update 2. The host platform is CentOS 6.5 (x86-64). It comes with gcc 4.4.7 and appropriate standart library. Both modules were compiled also with -O3. Shared object B is boost regex library version 1.55.0, if that matters. Boost by default builds with -ip if chosen toolset is intel-linux.

Hi Max,
There should not be any "incompatibility" issue with -ip. That said, it's just pure luck that it worked after you compiled C with -ip. The problem could be something else and we'll have to debug further to identify the real cause.
_Kittur
 

Max, did you have a chance to investigate further knowing that -ip should not have any incompatibility issue? -thx

Kittur, I've tried to make a simple test of three object files as I described above. Everything is fine. But when object B is libboost_regex compiled with Intel C++ 14, happens what I said above. I use boost 1.55 compiled with intel-linux toolset and by default it is compiled with -ip flag. If module C is also compiled with -ip, then it is OK.

I must say that module C doesn't even call anything from libboost_regex explicitly. Just the fact, that A is linked to libboost_regex is enough to reproduce.

Max, can you attach the sources of the small modules you say created the issue and the compile options you used? -thx

Kittur,

I've attached the test and a Makefile. You should rename Makefile.txt to Makefile and change BOOSTLIBDIR variable to point to directory that contains your boost shared libraries. Or just copy boost_regex to the current directory. Then simply type:

$ make

You are ready to execute test. Don't forget to set LD_LIBRARY_PATH to current directory. Otherwise libtestc.so wouldn't be found.

The test source code is not that pretty simple but I've stripped the code to the state when any line removal would make the test to run without the problem.

附件: 

附件尺寸
下载 test_1.cpp1.18 KB
下载 Makefile_1.txt375 字节

Thanks Max, just read your post. Let me download and try it out and will update you accordingly....

_Kittur

Max, well I tried your test case on my system with the correct version of boost (1.55) and making sure I'd the right version of GCC but couldn't reproduce the issue :-( See below:
-------------------------
[%]$ icpc -V
Intel(R) C++ Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 14.0.2.144 Build 20140120
Copyright (C) 1985-2014 Intel Corporation. All rights reserved.

[%]$ make clean
rm -f testa
rm -f libtest*.so
[%]$ make all
icpc -DUNIT_MAIN -DNDEBUG -o testa -std=c++0x -O3 -ldl -lboost_regex -L=/home/projects/boost_1_55/lib -Wl,-rpath-link==/home/projects/boost_1_55/lib test.cpp
icpc -DUNIT_LIBC -DNDEBUG -o libtestc.so -std=c++0x -O3 -shared -fPIC -Wl,-soname=libtestc.so test.cpp
[%]ls
libtestc.so Makefile testa test.cpp
[%]$ ./testa
[%]$
------------------------

_Regards,
Kittur

BTW, I even t tried your test scenario you mention at the start of the thread (with -ip) but couldn't reproduce the issue, fyi.

Kittur, I reproduce the problem on several machines running CentOS 6.5 and Scientific Linux 6.5, all of them running 64-bit OS. May be you can share the name of distro which you are using to reproduce the problem?

Also please check using ldd that testa links with correct version of boost. It may link with some other version of boost installed in your system in /usr/lib.

Also there is a chance that test executes successfully, because you have different stack or heap layout which can depend on various patches used by distro maintainers to strengthen security.

Anyway you could also try to run the test with valgrind. It can show problem event if it doesn't cause segfault. This is what I get when I run this test:

==21367== Memcheck, a memory error detector
==21367== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==21367== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==21367== Command: ./testa
==21367== 
==21367== Conditional jump or move depends on uninitialised value(s)
==21367==    at 0x4108CF: __intel_proc_init_ftzdazule (in /home/dmitrmax/work/tests/intel/testa)
==21367==    by 0x401B26: __intel_new_feature_proc_init (in /home/dmitrmax/work/tests/intel/testa)
==21367==    by 0x401482: main (in /home/dmitrmax/work/tests/intel/testa)
==21367== 
==21367== Conditional jump or move depends on uninitialised value(s)
==21367==    at 0x4108E4: __intel_proc_init_ftzdazule (in /home/dmitrmax/work/tests/intel/testa)
==21367==    by 0x401B26: __intel_new_feature_proc_init (in /home/dmitrmax/work/tests/intel/testa)
==21367==    by 0x401482: main (in /home/dmitrmax/work/tests/intel/testa)
==21367== 
==21367== Conditional jump or move depends on uninitialised value(s)
==21367==    at 0x5139D59: std::_Rb_tree<std::string, std::pair<std::string const, unsigned int>, std::_Select1st<std::pair<std::string const, unsigned int> >, std::less<std::string>, std::allocator<std::pair<std::string const, unsigned int> > >::_M_insert_unique(std::pair<std::string const, unsigned int> const&) (in /home/dmitrmax/work/boost-1.55/lib/libboost_regex-il-mt-1_55.so.1.55.0)
==21367==    by 0x93455B0: std::map<std::string, unsigned int, std::less<std::string>, std::allocator<std::pair<std::string const, unsigned int> > >::operator[](std::string const&) (in /home/dmitrmax/work/tests/intel/libtestc.so)
==21367==    by 0x9342006: func2 (in /home/dmitrmax/work/tests/intel/libtestc.so)
==21367==    by 0x4014FD: main (in /home/dmitrmax/work/tests/intel/testa)
==21367== 
==21367== Invalid read of size 8
==21367==    at 0x5139D6B: std::_Rb_tree<std::string, std::pair<std::string const, unsigned int>, std::_Select1st<std::pair<std::string const, unsigned int> >, std::less<std::string>, std::allocator<std::pair<std::string const, unsigned int> > >::_M_insert_unique(std::pair<std::string const, unsigned int> const&) (in /home/dmitrmax/work/boost-1.55/lib/libboost_regex-il-mt-1_55.so.1.55.0)
==21367==    by 0x93455B0: std::map<std::string, unsigned int, std::less<std::string>, std::allocator<std::pair<std::string const, unsigned int> > >::operator[](std::string const&) (in /home/dmitrmax/work/tests/intel/libtestc.so)
==21367==    by 0x9342006: func2 (in /home/dmitrmax/work/tests/intel/libtestc.so)
==21367==    by 0x4014FD: main (in /home/dmitrmax/work/tests/intel/testa)
==21367==  Address 0xffffffffffffffe8 is not stack'd, malloc'd or (recently) free'd
==21367== 
==21367== 
==21367== Process terminating with default action of signal 11 (SIGSEGV)
==21367==  Access not within mapped region at address 0xFFFFFFFFFFFFFFE8
==21367==    at 0x5139D6B: std::_Rb_tree<std::string, std::pair<std::string const, unsigned int>, std::_Select1st<std::pair<std::string const, unsigned int> >, std::less<std::string>, std::allocator<std::pair<std::string const, unsigned int> > >::_M_insert_unique(std::pair<std::string const, unsigned int> const&) (in /home/dmitrmax/work/boost-1.55/lib/libboost_regex-il-mt-1_55.so.1.55.0)
==21367==    by 0x93455B0: std::map<std::string, unsigned int, std::less<std::string>, std::allocator<std::pair<std::string const, unsigned int> > >::operator[](std::string const&) (in /home/dmitrmax/work/tests/intel/libtestc.so)
==21367==    by 0x9342006: func2 (in /home/dmitrmax/work/tests/intel/libtestc.so)
==21367==    by 0x4014FD: main (in /home/dmitrmax/work/tests/intel/testa)
==21367==  If you believe this happened as a result of a stack
==21367==  overflow in your program's main thread (unlikely but
==21367==  possible), you can try to increase the size of the
==21367==  main thread stack using the --main-stacksize= flag.
==21367==  The main thread stack size used in this run was 8388608.
==21367== 
==21367== HEAP SUMMARY:
==21367==     in use at exit: 1,481 bytes in 7 blocks
==21367==   total heap usage: 8 allocs, 1 frees, 1,665 bytes allocated
==21367== 
==21367== LEAK SUMMARY:
==21367==    definitely lost: 16 bytes in 1 blocks
==21367==    indirectly lost: 0 bytes in 0 blocks
==21367==      possibly lost: 29 bytes in 1 blocks
==21367==    still reachable: 1,436 bytes in 5 blocks
==21367==         suppressed: 0 bytes in 0 blocks
==21367== Rerun with --leak-check=full to see details of leaked memory
==21367== 
==21367== For counts of detected and suppressed errors, rerun with: -v
==21367== Use --track-origins=yes to see where uninitialised values come from
==21367== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 9 from 9)

 

Max, you're correct I had to try it on an equivalent EL6.X system as I don't have access to Cent OS in our lab (as it's not an officially supported system but should work. We test out issues on EL per-se). Assuiming it does segv, then what you're saying is that by compiling the libtestc.so with -ip the issue goes away, correct? What I'll do is to file this issue with our developers letting them know that it's happenning on your system and that I am not able to reproduce yet due to system/distro issue and see if they can try out also. I'll keep you updated as soon as there's any info on the filed issue. Hope that helps? For now as a workaround you can use -ip and get by, right?

Thanks,
Kittur

> please check using ldd that testa links with correct version of boost. It may link with some other version of boost installed in your system in /usr/lib.

Max, I did check and of course it does link to the correct version of boost

> please check using ldd that testa links with correct version of boost. It may link with some other version of boost installed in your system in /usr/lib.

Max, I did check and of course it does link to the correct version of boost

[%]$ gcc --version
gcc (GCC) 4.7.0 20120507 (Red Hat 4.7.0-5)

[%]$ ldd ./testa
linux-vdso.so.1 => (0x00007fff5aec0000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003bdc600000)
libboost_regex.so.1.55.0 => /home/projects/libboost_regex.so.1.55.0 (0x00007fb862304000)
libm.so.6 => /lib64/libm.so.6 (0x0000003bdca00000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x0000003be0a00000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003bde200000)
libc.so.6 => /lib64/libc.so.6 (0x0000003bdc200000)
/lib64/ld-linux-x86-64.so.2 (0x0000003bdba00000)
librt.so.1 => /lib64/librt.so.1 (0x0000003bdd200000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003bdce00000)

Unfortunately, don't have access to Valgrind but I'll download and test it out and see if I can reproduce there.
Also, I'll pass this on to our developers and will keep you updated accordingly, appreciate much.

_kittur

Kittur, I hope that your devs will have more luck. Anyway, I noticed that wrong GCC was used on your test environment.

[%]$ gcc --version
gcc (GCC) 4.7.0 20120507 (Red Hat 4.7.0-5)

While I wrote that this issue is reproducible when GCC 4.4.7 is used which is default on EL 6.x and its derived distributions (like CentOS or Scientific Linix). This may play a key role, since GCC 4.7.0 possibly comes with different standard library which contains affected std::map implementation.

 

Max, there you go - you're correct that'll make a difference in the test case used. Sure, let me make sure I rerun using the exact version of gcc and let you know, thanks.

_Kittur

Hi Max,
Thanks, that did it - I am able to reproduce the issue after using the exact version of gcc containing the correct std lib affecting the std:map implementation. I'll file this issue with developers so we can investigate what made the problem disappear (some inlining or any optimization?) after compiling with -ip. Appreciate your patience till then.
_Kittur

Good news - I'm not mad :) Hope this will be fixed in the next release.

I know yuo're aren't Max! I'll touch base with you as soon as I've update on the issue I've filed with our developers after their investigation accordingly. Again, as always appreciate your patience.....

_kittur

Max, I just tried with our latest 15.0 beta version of our compiler and it passes successfully. I'll keep you updated as soon as the 15.0 version is released. In the meantime, let me know if you want me to add your name to the beta invite list for 15.0?

_Regards, Kittur

Max, I just tried with our latest 15.0 beta version of our compiler and it passes successfully. I'll keep you updated as soon as the 15.0 version is released. In the meantime, let me know if you want me to add your name to the beta invite list for 15.0?

_Regards, Kittur

Max, I just tried with our latest 15.0 beta version of our compiler and it passes successfully. I'll keep you updated as soon as the 15.0 version is released. In the meantime, let me know if you want me to add your name to the beta invite list for 15.0?

_Regards, Kittur

Kittur, why not? It's better to find problems before release ) So feel free to add me to the beta invite list.

Also, it would be good to know if I've chosen the right workaround of this problem with current compiler version. I mean compiling my code with -ip switch. Theoretically it could be so, that it just hides the problem and crashes can happen in other places or in other conditions.

Max, I agree and I've passed on your name to the beta coordinator for adding to the beta invite list. With regard to whether using -ip as a workaround I am awaiting a response from our dev team and will update you as soon as I get a confirmation. Again, appreciate your patience :-)

_Kittur

Max, this issue is still being investigated by our dev team and will keep you updated as soon as I've some response on their investigation, fyi.

_kittur

Hi Max, 
Thanks for your patience, the latest 15.0 Update 1 release contains the fix for this issue  which you can download from the Intel Registration Center, appreciate much.
_Kittur 

发表评论

登录添加评论。还不是成员?立即加入