[MEGOLDVA] ldconfig - SIGSEGV

Linux-haladó

Jó ideje töröm már a fejem, de csak nem tudok rájönni mi a fene baja van az ldconfig-omnak: 

[root@Ishikawa /]# ldconfig
Segmentation fault (core dumped)
[root@Ishikawa /]# strace -i ldconfig
[00007fb840c1fe07] execve("/sbin/ldconfig", ["ldconfig"], [/* 30 vars */]) = 0
[000000000048a5c7] uname({sysname="Linux", nodename="Ishikawa", ...}) = 0
[000000000048ae69] brk(0)               = 0x1e4d000
[000000000048ae69] brk(0x1e4e1c0)       = 0x1e4d000
[000000000048aeaf] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xffffffffffffffd0} ---
[????????????????] +++ killed by SIGSEGV (core dumped) +++
Segmentation fault (core dumped)

Az ldconfig hash értéke megegyezik egy másik gépen teljesen jól futó ldconfig-éval. A cache-t töröltem (/etc/ld.so.cache, illetve /var/cache/ldconfig/aux-cache ), confokat összenéztem, glibc-s csomagokat újratettem.. Nem látok különbséget.
Az viszont felettéb gyanús, hogy a heap pointer extendnél (brk) a pointerem értéke ugyan az marad.

OS: Fedora 22 (x64) 

[root@Ishikawa /]# rpm -qa |grep glibc
glibc-common-2.21-8.fc22.x86_64
glibc-devel-2.21-8.fc22.x86_64
glibc-headers-2.21-8.fc22.x86_64
glibc-2.21-8.fc22.x86_64
glibc-2.21-8.fc22.i686

Látott már valaki hasonlót?

Szerk: 

[root@Ishikawa tmp]# rpm -qp --scripts glibc-2.21-8.fc22.x86_64.rpm
preinstall scriptlet (using <lua>):
-- Check that the running kernel is new enough
required = '2.6.32'
rel = posix.uname("%r")
if rpm.vercmp(rel, required) < 0 then
  error("FATAL: kernel too old", 0)
end
postinstall program: /usr/sbin/glibc_post_upgrade.x86_64
postuninstall program: /sbin/ldconfig
[root@Ishikawa tmp]# strace -i /usr/sbin/glibc_post_upgrade.x86_64
[00007f48bea15e07] execve("/usr/sbin/glibc_post_upgrade.x86_64", ["/usr/sbin/glibc_post_upgrade.x86"...], [/* 30 vars */]) = 0
[000000000042b717] uname({sysname="Linux", nodename="Ishikawa", ...}) = 0
[000000000042b8e9] brk(0)               = 0x1339000
[000000000042b8e9] brk(0x133a1c0)       = 0x1339000
[000000000042b92f] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xffffffffffffffd0} ---
[????????????????] +++ killed by SIGSEGV (core dumped) +++
Segmentation fault (core dumped)

Meg se lepődök...

szerk: Ulimit issue. Valahogy a data segment size-om 0-ra állítódott, bár meg nem mondhatom hogyan.. ulimit -d unlimited megoldott a problémát

( vl v | 2015. 10. 31., szo – 15:15 )

BTW, az miért jó, hogy nagybetű van a hostnévben? Nem szoptál még vele soha?

Nem. Bár túl sok mindenre nem is használom a gépen a hostnevet (tehát nincs a gép tartományban, vagy bármi hasonló)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

( NevemTeve | 2015. 10. 31., szo – 20:08 )

Asszem most kellene ldconfig-ot fordítani debuggal. (Persze Murphy idevágó törvénye szerint az meg hibátlanul fog működni.)

Valami más lesz itt.
- Megnéztem egy backupot (ahol még nem volt gond) -> SIGSEGV
- Forgattam forrásból -> SIGSEGV
- Áthoztam egy másik gépről ahol az ldconfig teljesen jól működik -> SIGSEGV
Illetve mint írtam más program is ugyan ezt csinálja (glibc_post_upgrade.x86_64), és mind2 esetben ott áll meg a process, hogy a heap pointer a brk után nem mozdul sehova: 

[00007f8d084a2e07] execve("./ldconfig", ["./ldconfig", "-d"], [/* 30 vars */]) = 0
[0000000000476917] uname({sysname="Linux", nodename="Ishikawa", ...}) = 0
[00000000004771b9] brk(0)               = 0x2532000
[00000000004771b9] brk(0x25331c0)       = 0x2532000
[00000000004771ff] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xffffffffffffffd0} ---

____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Nekem is ez volt az egyik első gondolatom amikor a heap-et néztem. De az elérhető 3 kernel közül mindegyiknél ugyan ezzel a problémával lehal az ldconfig: 

[root@Ishikawa elf]# ls -l /boot/vmlinuz-*
-rwxr-xr-x. 1 root root 5519992 Jan 24  2015 /boot/vmlinuz-0-rescue-f45b3d03cea54c3aa39c0c21f05f77e3
-rwxr-xr-x. 1 root root 5964056 Oct  5 16:32 /boot/vmlinuz-4.1.10-200.fc22.x86_64
-rwxr-xr-x. 1 root root 5961112 Sep 14 22:25 /boot/vmlinuz-4.1.7-200.fc22.x86_64
-rwxr-xr-x. 1 root root 5978744 Oct  8 05:30 /boot/vmlinuz-4.2.3-200.fc22.x86_64
-rw-r--r--. 1 root root 5897400 May 21 15:16 /boot/vmlinuz-fedup

Amúgy a /etc/ld.so.cache alapján Oct. 3.-án még sikerült lefutnia az ldconfig-nak, szóval a 4.1.7essel mennie kellene ha a kernel lenne a hiba.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Na most lehet hülyeséget fogok kérdezni, de használható az statikus linkelés esetén (mint amilyen az ldconfig is)? 

[root@Ishikawa elf]# ltrace -i ldconfig
Couldn't find .dynsym or .dynstr in "/proc/25539/exe"

____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Azért értékelem a segítő szándékot :) Amúgy Google-t én már 2 napja bújom, de van egy olyan érzésem, hogy ez nem ldconfig specifikus issue lesz, hanem valami általánosabb (csak tudnám mi), tekintve hogy mint fentebb írtam minimum 2 proginál is szembejön ez (bár nem tudom, hogy mennyire osztozik a 2 kódbázisa) a brk-s furcsaság.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

( Huncraft v | 2015. 11. 01., v – 12:38 )

Na jó... csessze meg az élet :D 

The brk subroutine and the sbrk subroutine are unsuccessful and the allocated space remains unchanged if one or more of the following are true:

ENOMEM	The requested change allocates more space than is allowed by a system-imposed maximum. (For information on the system-imposed maximum on memory space, see the ulimit system call.)
ENOMEM	The requested change sets the break value to a value greater than or equal to the start address of any attached shared-memory segment. (For information on shared memory operations, see the shmat subroutine.)
[root@Ishikawa ~]# ulimit -d
0
[root@Ishikawa ~]# ldconfig
Segmentation fault (core dumped)
[root@Ishikawa ~]# ulimit -d unlimited
[root@Ishikawa ~]# ldconfig
[root@Ishikawa ~]# echo $?
0

De hogy a data segment size-om miért ált be 0ra arról fogalmam nincs.. Azt hiszem érdemes lesz átnéznem mi változott a /etc/security/limits.conf alatt az elmúlt időben

____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..