[petsc-users] problems after glibc upgrade to 2.17-157

[Satish Balay]

On Thu, 5 Jan 2017, Matthew Knepley wrote:

> On Thu, Jan 5, 2017 at 2:37 AM, Klaij, Christiaan <C.Klaij at marin.nl> wrote:

> > So problem solved for now, thanks to you and Matt for all your
> > help! On the long run I will go for Intel-17 on SL7.3.
> >
> > What worries me though is that a simple update (which happens all
> > the time according to sysadmin) can have such a dramatic effect.
> >
> I agree. It seems SL has broken the ability to use shared libraries with a
> simple point release.
> It seems the robustness of all this process is a myth.

Well its more of RHEL - than SL. And its just Intel .so files [as far
as we know] thats triggering this issue.

RHEL generally doesn't make changes that break old binaries. But any
code change [wihch bug fixes are] - can introduce changed behavior
with some stuff.. [esp stuff that might use internal - non-api
features]

RHEL7 glibc had huge number of fixes since 2.17-106.el7_2.8
https://rpmfind.net/linux/RPM/centos/updates/7.3.1611/x86_64/Packages/glibc-2.17-157.el7_3.1.x86_64.html

Interestingly the code crashes at dynamic linking time? [ even before
main() starts] - perhaps something to do with the way libintlc.so.5
uses memmove?

(gdb) where
#0  0x00007ffff722865e in ?? ()
#1  0x00007ffff7de9675 in elf_machine_rela (reloc=0x7ffff592ae38, reloc=0x7ffff592ae38, skip_ifunc=<optimized out>, reloc_addr_arg=0x7ffff5b8e8f0, version=0x0, sym=0x7ffff5925f58, map=0x7ffff7fee570)
    at ../sysdeps/x86_64/dl-machine.h:288
#2  elf_dynamic_do_Rela (skip_ifunc=<optimized out>, lazy=<optimized out>, nrelative=<optimized out>, relsize=<optimized out>, reladdr=<optimized out>, map=0x7ffff7fee570) at do-rel.h:170
#3  _dl_relocate_object (scope=<optimized out>, reloc_mode=<optimized out>, consider_profiling=<optimized out>, consider_profiling at entry=0) at dl-reloc.c:259
#4  0x00007ffff7de0792 in dl_main (phdr=<optimized out>, phdr at entry=0x400040, phnum=<optimized out>, phnum at entry=9, user_entry=user_entry at entry=0x7fffffffceb8, auxv=<optimized out>) at rtld.c:2192
#5  0x00007ffff7df3e36 in _dl_sysdep_start (start_argptr=start_argptr at entry=0x7fffffffcf70, dl_main=dl_main at entry=0x7ffff7dde820 <dl_main>) at ../elf/dl-sysdep.c:244
#6  0x00007ffff7de1a31 in _dl_start_final (arg=0x7fffffffcf70) at rtld.c:318
#7  _dl_start (arg=0x7fffffffcf70) at rtld.c:544
#8  0x00007ffff7dde1e8 in _start () from /lib64/ld-linux-x86-64.so.2
#9  0x0000000000000001 in ?? ()
#10 0x00007fffffffd25c in ?? ()
#11 0x0000000000000000 in ?? ()
(gdb) 

[balay at localhost benchmarks]$ LD_DEBUG=all ./a.out
<snip>
      2468:	symbol=__xpg_basename;  lookup in file=./a.out [0]
      2468:	symbol=__xpg_basename;  lookup in file=/soft/com/packages/intel/16/u3/compilers_and_libraries_2016.3.210/linux/compiler/lib/intel64/libifcore.so.5 [0]
      2468:	symbol=__xpg_basename;  lookup in file=/lib64/libm.so.6 [0]
      2468:	symbol=__xpg_basename;  lookup in file=/lib64/libgcc_s.so.1 [0]
      2468:	symbol=__xpg_basename;  lookup in file=/lib64/libc.so.6 [0]
      2468:	binding file /soft/com/packages/intel/16/u3/compilers_and_libraries_2016.3.210/linux/compiler/lib/intel64/libintlc.so.5 [0] to /lib64/libc.so.6 [0]: normal symbol `__xpg_basename'
      2468:	symbol=memmove;  lookup in file=./a.out [0]
      2468:	symbol=memmove;  lookup in file=/soft/com/packages/intel/16/u3/compilers_and_libraries_2016.3.210/linux/compiler/lib/intel64/libifcore.so.5 [0]
      2468:	symbol=memmove;  lookup in file=/lib64/libm.so.6 [0]
      2468:	symbol=memmove;  lookup in file=/lib64/libgcc_s.so.1 [0]
      2468:	symbol=memmove;  lookup in file=/lib64/libc.so.6 [0]
      2468:	binding file /soft/com/packages/intel/16/u3/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)



If intel-16 compilers are critical - one can always downgrade to old
glibc - but then would miss out on all the fixes..

yum downgrade glibc*

Satish