idb 10.1.015 Segmentation fault on amd64 (opteron)

miro_ilias · ‎07-22-2008

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&n bsp; addb %al,(%rax)

pgdbg> where

STACK TRACE:

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

Any help is appreciated. Miro

Ron_Green · ‎07-22-2008

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

miro_ilias · ‎07-23-2008

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.

miro_ilias · ‎07-23-2008

Thanks for hints, Ron, working on it.

Miro

miro_ilias · ‎07-23-2008

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 Debugger for applications running on Intel 64, Version 10.1-35 , Build 20080310
(idb)

miro_ilias · ‎07-24-2008

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-r edhat-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.

miro_ilias · ‎07-27-2008

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").