Bug 1410576 - SEGV when linking with intel 16.0.3 compiler library libifcore.so
Summary: SEGV when linking with intel 16.0.3 compiler library libifcore.so
Status: CLOSED DUPLICATE of bug 1377895
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: glibc
Version: 7.3
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: glibc team
QA Contact: qe-baseos-tools-bugs
Depends On:
TreeView+ depends on / blocked
Reported: 2017-01-05 19:13 UTC by Satish Balay
Modified: 2017-01-25 14:13 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-01-25 14:13:26 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Satish Balay 2017-01-05 19:13:13 UTC
Description of problem:

After upgrade to latest glibc - binaries that are compiled with intel 16.0.3 - that use shared libraries break giving SEGV

Version-Release number of selected component (if applicable):

-bash-4.2$ rpm -q glibc
-bash-4.2$ cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 7.3 (Maipo)

How reproducible:


Steps to Reproduce:
1. install intel compilers 16.0.3
2. compile any code with 'icc -lifcore'
3. run

Actual results:

Segmentation fault (core dumped)

Expected results:

No such error.

Additional info:

This issue was initially observed on SL7 - and reproduced on CENTOS7 - and now on RHEL7 aswell.

 -bash-4.2$ icc --version
icc (ICC) 16.0.3 20160415
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.

-bash-4.2$ cat x.c
#include <stdio.h>
int main() { printf("test\n");return 0; }
-bash-4.2$ icc x.c
-bash-4.2$ ./a.out 
-bash-4.2$ icc x.c -lifcore
-bash-4.2$ ./a.out 
Segmentation fault (core dumped)
-bash-4.2$ gdb a.out
(gdb) where
#0  0x00007ffff722865e in ?? ()
#1  0x00007ffff7de9675 in _dl_relocate_object () from /lib64/ld-linux-x86-64.so.2
#2  0x00007ffff7de0792 in dl_main () from /lib64/ld-linux-x86-64.so.2
#3  0x00007ffff7df3e36 in _dl_sysdep_start () from /lib64/ld-linux-x86-64.so.2
#4  0x00007ffff7de1a31 in _dl_start () from /lib64/ld-linux-x86-64.so.2
#5  0x00007ffff7dde1e8 in _start () from /lib64/ld-linux-x86-64.so.2
#6  0x0000000000000001 in ?? ()
#7  0x00007fffffffb6b3 in ?? ()
#8  0x0000000000000000 in ?? ()

-bash-4.2$ LD_DEBUG=all ./a.out
    219423:	symbol=__xpg_basename;  lookup in file=./a.out [0]
    219423:	symbol=__xpg_basename;  lookup in file=/opt/intel/2016u3/compilers_and_libraries_2016.3.210/linux/compiler/lib/intel64/libifcore.so.5 [0]
    219423:	symbol=__xpg_basename;  lookup in file=/lib64/libm.so.6 [0]
    219423:	symbol=__xpg_basename;  lookup in file=/lib64/libgcc_s.so.1 [0]
    219423:	symbol=__xpg_basename;  lookup in file=/lib64/libc.so.6 [0]
    219423:	binding file /opt/intel/2016u3/compilers_and_libraries_2016.3.210/linux/compiler/lib/intel64/libintlc.so.5 [0] to /lib64/libc.so.6 [0]: normal symbol `__xpg_basename'
    219423:	symbol=memmove;  lookup in file=./a.out [0]
    219423:	symbol=memmove;  lookup in file=/opt/intel/2016u3/compilers_and_libraries_2016.3.210/linux/compiler/lib/intel64/libifcore.so.5 [0]
    219423:	symbol=memmove;  lookup in file=/lib64/libm.so.6 [0]
    219423:	symbol=memmove;  lookup in file=/lib64/libgcc_s.so.1 [0]
    219423:	symbol=memmove;  lookup in file=/lib64/libc.so.6 [0]
    219423:	binding file /opt/intel/2016u3/compilers_and_libraries_2016.3.210/linux/compiler/lib/intel64/libintlc.so.5 [0] to /lib64/libc.so.6 [0]: normal symbol `memmove'
Segmentation fault (core dumped)

Downgrading glibc to 2.17-106.el7_2.8 gets this working.

And intel compilers versions 17.0.0, 17.0.1 do not have this issue.

This could very well be due to bugs in intel 16.0.3 compiler..

Comment 1 Florian Weimer 2017-01-05 19:56:59 UTC
This looks like a duplicate of bug 1377895.

Satish, based on your comments, I assume that the issue does not just affect the Intel compiler binaries, but also code which was compiled with the Intel compilers.  This is new information; I was previously under the impression that it would only affect the compilers themselves.  Would you please confirm that once more?

Comment 2 Satish Balay 2017-01-05 20:38:23 UTC
I did not see icc give SEGV in my usage.

The errors I've seen so far are with binaries created by the compiler - that are linked with some of the compiler .so files - as I've documented in this report.

The initial issue was as follows:
- [before upgrade] compile library/binaries with intel compilers. [they work!]
- upgrade glibc
- now the previously running binaries [that were compiled with intel compiler (which were linked to some of the compiler sharedlibraries - like libifcore.so) ] give SEGV.

Static builds [that use libifcore.a - not .so ] work fine.
[For eg: a static build of mpich works fine..]

BTW: wrt bug 1377895 - mpicc is a icc binary - using its .so library files - hence it breaks.. ['ldd mpicc' lists 'libintlc.so.5' this one also gets listed in the simple test code breakage above.]

Comment 3 Satish Balay 2017-01-06 16:20:53 UTC
One additional note regarding LD_PRELOAD wokraround.

It works with existing precompiled icc binaries. However - when using buildscripts (like configure - which can do compile/run tests etc.) which invoke both gcc binaries [like env, uname etc..] and icc binaries - its not easy to selectively use this workaround with only icc binaries.

using LD_PRELOAD universally with such buildscripts causes gcc binaries to crash..

-bash-4.2$ LD_PRELOAD=/lib64/libc.so.6:/opt/intel/2016u3/lib/intel64/libintlc.so.5 uname
Segmentation fault (core dumped)
-bash-4.2$ LD_PRELOAD=/lib64/libc.so.6:/opt/intel/2016u3/lib/intel64/libintlc.so.5 env
Segmentation fault (core dumped)

To really use intel-16 compilers - the alternative that works for me is to copy libintlc.so.5 from intel-17 to intel-16 compiler location. [replacing the intel-16 version]

[yeah - it requires access to intel-17 - and if one has that - one could perhaps switch to intel-17]

Comment 4 Florian Weimer 2017-01-25 14:13:26 UTC
Intel published a support article regarding this matter:


*** This bug has been marked as a duplicate of bug 1377895 ***

Note You need to log in before you can comment on or make changes to this bug.