RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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.