Intel® Software Network

Greetings !

I have installed fresh Intel Fortran package (l_fc_p_10.1.015_intel64.tar.gz) on our opteron server (Linux version 2.6.9-11.ELsmp; gcc version 3.4.3 20050227 - Red Hat 3.4.3-22.

Though ifort is working well but  the "idb" gives always "Segmentation fault."

miro@opteron.tau.ac.il:/opt/intel/idbe/10.1.015/bin/.idb
Segmentation fault


Closer look (debugging the "idb-e" executable with other debuggers) shows this:
----------------------------------------------------------------------------------
miro@opteron.tau.ac.il:/opt/intel/idbe/10.1.015/bin/.gdb idb-e
GNU gdb Red Hat Linux (6.3.0.0-0.31rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...(no debugging symbols found)
Using host libthread_db library "/lib64/tls/libthread_db.so.1".

(gdb) r
Starting program: /opt/intel/idbe/10.1.015/bin/idb-e
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
0x0000002a955bb470 in operator new () from /usr/lib/gcc-lib/x86_64-redhat-linux/3.3.4/libstdc++.so.5
-----------------------------------------------------------------------------------------------------------

Now check with the "pgdbg":
miro@opteron.tau.ac.il:/opt/intel/idbe/10.1.015/bin/.pgdbg idb-e

pgdbg: Cannot Open Display. Check your DISPLAY
variable. Using Text Interface.

NOTE: your trial license will expire in 9 days, 3.16 hours.
NOTE: your trial license will expire in 15 days, 0.56 hours.
PGDBG 7.2-3 x86-64 (Cluster, 8 Process)
Copyright 1989-2000, The Portland Group, Inc. All Rights Reserved.
Copyright 2000-2008, STMicroelectronics, Inc. All Rights Reserved.
Loaded: /opt/intel/idbe/10.1.015/bin/idb-e
NOTE: Can't find main function compiled -g


pgdbg> run
libdl.so.2 loaded by ld-linux-x86-64.so.2.
libXt.so.6 loaded by ld-linux-x86-64.so.2.
libXrender.so.1 loaded by ld-linux-x86-64.so.2.
libXft.so.2 loaded by ld-linux-x86-64.so.2.
libfreetype.so.6 loaded by ld-linux-x86-64.so.2.
libXext.so.6 loaded by ld-linux-x86-64.so.2.
libX11.so.6 loaded by ld-linux-x86-64.so.2.
libSM.so.6 loaded by ld-linux-x86-64.so.2.
libICE.so.6 loaded by ld-linux-x86-64.so.2.
libm.so.6 loaded by ld-linux-x86-64.so.2.
libstdc++.so.5 loaded by ld-linux-x86-64.so.2.
libc.so.6 loaded by ld-linux-x86-64.so.2.
libfontconfig.so.1 loaded by ld-linux-x86-64.so.2.
libexpat.so.0 loaded by ld-linux-x86-64.so.2.
libz.so.1 loaded by ld-linux-x86-64.so.2.
Signalled SIGSEGV at 0x2A955BB470, function _Znwm
0x2A955BB470:  0 0                      addb   %al,(%rax)

pgdbg> where

STACK TRACE:

   #2  <unknown-address> address: 0x11D3E29
   #1  _ZN18QMetaObjectCleanUpC1EPKcPFP11QMetaObjectvE address: 0xFBE177
*** Stack frames number 1 and higher may be incorrect ***
=> #0  _Znwm address: 0x2A955BB470


Any help is appreciated. Miro

Can you double check your RHEL version?  Kernel 2.6.9-11 is, to my recollection, RHEL 4.1.  And does uname -a return x86_64 and not i386?

And send the output of:

ls -l /usr/lib/libstdc++.so.5*

and

rpm -qa | grep glibc  - is this at glibc-2.3.xx-xxx ?

and

ldd /opt/intel/idbe/10.1.015/bin/idb-e

Hopefully libstdc++.so.5 is coming from /usr/lib64 and NOT /usr/lib (32bit version).

Make sure you
source /opt/intel/idbe/10.1.015/bin/idbvars.sh
or
   idbvars.csh  (depending on your shell)


thanks

ron

In continuation to find out the source I installed Intel Fortran on 64bit PC, debian linux.

The error message is:

ilias@miro.utcpd.sk:~/.idb
/opt/intel/idbe/10.1.015/bin/idb-e: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory

Seems the error is in libraries....

M.

Thanks for hints, Ron, working on it.

Miro

miro_ilias:

In continuation to find out the source I installed Intel Fortran on 64bit PC, debian linux.

The error message is:

ilias@miro.utcpd.sk:~/.idb
/opt/intel/idbe/10.1.015/bin/idb-e: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory

Seems the error is in libraries....

M.

I have fix it ! Simply by installing the debian "libstdc++5" package (I have the newest one, "libstdc++6").

ilias@miro.utcpd.sk:/opt/intel/fce/10.1.015/bin/.dpkg -S  /usr/lib/libstdc++.so.5
libstdc++5: /usr/lib/libstdc++.so.5
ilias@miro.utcpd.sk:/opt/intel/fce/10.1.015/bin/.idb
Intel(R) Debugger for applications running on Intel(R) 64, Version 10.1-35 , Build 20080310
(idb)

Hi,

Can you double check your RHEL version?  Kernel 2.6.9-11 is, to my recollection, RHEL 4.1.  And does uname -a return x86_64 and not i386?


Regarding the RHEL version (from /etc/redhat-release) we have
Red Hat Enterprise Linux WS release 4 (Nahant Upda te 1)

[root@opteron ~]# uname -a
Linux opteron.tau.ac.il 2.6.9-11.ELsmp #1 SMP Fri May 20 18:25:30 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux

We have x86_64.

And send the output of:
ls -l /usr/lib/libstdc++.so.5*

Here:
[root@opteron ~]# ls -l /usr/lib/libstdc++.so.5*
lrwxrwxrwx  1 root root      18 Sep  7  2005 /usr/lib/libstdc++.so.5 -> libstdc++.so.5.0.7
-rwxr-xr-x  1 root root 733488 Dec  1  2004 /usr/lib/libstdc++.so.5.0.7

and
rpm -qa | grep glibc  - is this at glibc-2.3.xx-xxx ?


Yes, it is:
[root@opteron ~]# rpm -qa | grep glibc 
glibc-2.3.4-2.9
glibc-devel-2.3.4-2.9
glibc-common-2.3.4-2.9
glibc-devel-2.3.4-2.9
compat-glibc-2.3.2-95.30
glibc-2.3.4-2.9
glibc-headers-2.3.4-2.9
glibc-kernheaders-2.4-9.1.87
compat-glibc-headers-2.3.2-95.30
 
and
ldd /opt/intel/idbe/10.1.015/bin/idb-e
[root@opteron ~]# ldd /opt/intel/idbe/10.1.015/bin/idb-e
        libdl.so.2 => /lib64/libdl.so.2 (0x0000003bc2a00000)
        libXt.so.6 => /usr/X11R6/lib64/libXt.so.6 (0x0000003bc6100000)
        libXrender.so.1 => /usr/X11R6/lib64/libXrender.so.1 (0x0000003bc4300000)
        libXft.so.2 => /usr/X11R6/lib64/libXft.so.2 (0x0000003bc4900000)
        libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x0000003bc3d00000)
        libXext.so.6 => /usr/X11R6/lib64/libXext.so.6 (0x0000003bc3300000)
        libX11.so.6 => /usr/X11R6/lib64/libX11.so.6 (0x0000003bc3100000)
        libSM.so.6 => /usr/X11R6/lib64/libSM.so.6 (0x0000003bc3900000)
        libICE.so.6 => /usr/X11R6/lib64/libICE.so.6 (0x0000003bc3700000)
        libm.so.6 => /lib64/tls/libm.so.6 (0x0000003bc2f00000)
        libstdc++.so.5 => /usr/lib/gcc-lib/x86_64-redhat-linux/3.3.4/libstdc++.so.5 (0x0000002a95580000)
        libc.so.6 => /lib64/tls/libc.so.6 (0x0000003bc2c00000)
        libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x0000003bc3f00000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003bc2800000)
        libexpat.so.0 => /usr/lib64/libexpat.so.0 (0x0000003bc4100000)
        libz.so.1 => /usr/lib64/libz.so.1 (0x0000003bc3500000)

Hopefully libstdc++.so.5 is coming from /usr/lib64 and NOT /usr/lib (32bit version).

it's coming from
libstdc++.so.5 => /usr/lib/gcc-lib/x86_64-redhat-linux/3.3.4/libstdc++.so.5
where
[root@opteron ~]# ls -lt /usr/lib/gcc-lib/x86_64-redhat-linux/3.3.4/libstdc++.so.5
lrwxrwxrwx  1 root root 12 Sep 13  2005 /usr/lib/gcc-lib/x86_64-redhat-linux/3.3.4/libstdc++.so.5 -> libstdc++.so

The package:
[root@opteron 3.3.4]# rpm -q -f  libstdc++.so.5
compat-libstdc++-33-3.2.3-47.3

Make sure you
source /opt/intel/idbe/10.1.015/bin/idbvars.sh
or
   idbvars.csh  (depending on your shell)

I have it in $PATH and $MANPATH.

How it was solved: from /etc/ld.so.conf  the line with "/usr/lib/gcc-lib/x86_64-redhat-linux/3.3.4" was removed.

The problem was that the loader found an incorrect "libstdc++.so.5" in its path - from
/usr/lib/gcc-lib/x86_64-redhat-linux/3.3.4 instead of the correct one in /usr/lib64.

These libraries, though with identical names, differ:

lrwxrwxrwx  1 root root 18 Sep  7  2005 /usr/lib64/libstdc++.so.5 -> libstdc++.so.5.0.7*
-rwxr-xr-x  1 root root 825496 Dec  1  2004 /usr/lib64/libstdc++.so.5.0.7*
vs
-rw-r--r--  1 root root 302880 Dec  1  2004 /usr/lib/gcc-lib/x86_64-redhat-linux/3.3.4/libstdc++.so

Since they belong  to different installation packages:    libstdc++-3.4.3-22.1 vs compat-libstdc++-33-3.2.3-47.3 ("bad guy").