Seems like corrupted system -- reinstallation with HDD formatting may be helpful.
Also, if you interested in details, you may get core dump by setting of 'ulimit -c unlimited', install of debuginfo packages and examine of dumped state by gdb: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Developer_Guide/debugging.html On Wed, Jun 25, 2014 at 7:19 PM, Werf, C.G. van der (Carel) <[email protected]> wrote: > Ofcourse, if # rpm -Va is segfaulting, so does #rpm -V libsepol > > -----Original Message----- > From: Oleg Sadov [mailto:[email protected]] > Sent: woensdag 25 juni 2014 17:13 > To: Werf, C.G. van der (Carel) > Cc: Pat Riehecky; [email protected] > Subject: Re: [SCIENTIFIC-LINUX-USERS] yum segfaulting > > What about rpm -V libsepol ? > > On Wed, Jun 25, 2014 at 6:25 PM, Werf, C.G. van der (Carel) > <[email protected]> wrote: >> # ldd /bin/rpm >> librpm-4.4.so => /usr/lib64/librpm-4.4.so (0x00000034be400000) >> librpmdb-4.4.so => /usr/lib64/librpmdb-4.4.so (0x00000034be000000) >> libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003744000000) >> librpmio-4.4.so => /usr/lib64/librpmio-4.4.so (0x00000034bdc00000) >> libpopt.so.0 => /usr/lib64/libpopt.so.0 (0x0000003748c00000) >> libsqlite3.so.0 => /usr/lib64/libsqlite3.so.0 (0x0000003745000000) >> libelf.so.1 => /usr/lib64/libelf.so.1 (0x0000003744400000) >> libm.so.6 => /lib64/libm.so.6 (0x0000003742c00000) >> libz.so.1 => /usr/lib64/libz.so.1 (0x0000003743800000) >> libnss3.so => /usr/lib64/libnss3.so (0x00000034bd800000) >> libnssutil3.so => /usr/lib64/libnssutil3.so (0x00000034bd400000) >> libplds4.so => /usr/lib64/libplds4.so (0x0000003b82600000) >> libplc4.so => /usr/lib64/libplc4.so (0x0000003b82a00000) >> libnspr4.so => /usr/lib64/libnspr4.so (0x0000003b81a00000) >> libdl.so.2 => /lib64/libdl.so.2 (0x0000003742800000) >> librt.so.1 => /lib64/librt.so.1 (0x0000003743400000) >> libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003743000000) >> libbz2.so.1 => /usr/lib64/libbz2.so.1 (0x0000003757200000) >> libc.so.6 => /lib64/libc.so.6 (0x0000003742400000) >> libsepol.so.1 => /lib64/libsepol.so.1 (0x000000319b000000) >> /lib64/ld-linux-x86-64.so.2 (0x0000003742000000) >> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003752200000) >> >> Looks exactly the same on both systems (the "working" and the >> "segfaulting" one) >> >> Carel >> -----Original Message----- >> From: Pat Riehecky [mailto:[email protected]] >> Sent: woensdag 25 juni 2014 16:20 >> To: Werf, C.G. van der (Carel); >> [email protected] >> Subject: Re: [SCIENTIFIC-LINUX-USERS] yum segfaulting >> >> Indeed! >> >> anything curious on ldd of rpm? >> >> Pat >> >> On 06/25/2014 09:11 AM, Werf, C.G. van der (Carel) wrote: >>> Hi Pat, >>> >>> # ldd /lib64/libsepol.so.1 >>> libc.so.6 => /lib64/libc.so.6 (0x0000003742400000) >>> /lib64/ld-linux-x86-64.so.2 (0x0000003742000000) >>> >>> # rpm -Va >>> Segmentation fault >>> >>> Ha, that's interesting ... it might be rpm after all ? >>> >>> >>> Carel >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Pat Riehecky [mailto:[email protected]] >>> Sent: woensdag 25 juni 2014 16:03 >>> To: Werf, C.G. van der (Carel); >>> [email protected] >>> Subject: Re: [SCIENTIFIC-LINUX-USERS] yum segfaulting >>> >>> I'm a bit curious what does >>> >>> ldd /lib64/libsepol.so.1 >>> >>> report? >>> >>> Also, you may want to try: >>> >>> rpm -Va >>> >>> That will take loads of time, but may report something interesting. >>> >>> Pat >>> >>> On 06/25/2014 07:44 AM, Werf, C.G. van der (Carel) wrote: >>>> Running an strace still offers no clues to this problem... >>>> >>>> >>>> When running: >>>> # strace yum --help 2>&1 | cat > yum-tracelog >>>> >>>> >>>> I see this at the end of the log. >>>> >>>> open("/lib64/libsepol.so.1", O_RDONLY) = 6 read(6, >>>> "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0=\300C7\0\0\0"..., >>>> 832) = 832 fstat(6, {st_mode=S_IFREG|0755, st_size=247496, ...}) = 0 >>>> mmap(0x3743c00000, 2383136, PROT_READ|PROT_EXEC, >>>> MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x3743c00000 >>>> mprotect(0x3743c3b000, 2097152, PROT_NONE) = 0 mmap(0x3743e3b000, >>>> 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, >>>> 0x3b000) = 0x3743e3b000 mmap(0x3743e3c000, 40224, PROT_READ|PROT_WRITE, >>>> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x3743e3c000 >>>> close(6) = 0 >>>> --- SIGSEGV (Segmentation fault) @ 0 (0) --- >>>> +++ killed by SIGSEGV +++ >>>> << >>>> >>>> So after closing /lib64/libsepol.so.1, the segfault is triggered. >>>> >>>> But, since I disabled selinux, why is there a call to libsepol.so.1 ? >>>> >>>> >>>> On a my mirror-server, the same call to # yum --help" does work without >>>> segfault. >>>> An strace in this situation, will show that after closing the >>>> /lib64/libespol.so.1 the next commands are traced ... >>>> >>>> mprotect(0x319a607000, 4096, PROT_READ) = 0 >>>> access("/etc/selinux/", F_OK) = 0 >>>> open("/etc/selinux/config", O_RDONLY) = 6 >>>> fstat(6, {st_mode=S_IFREG|0644, st_size=511, ...}) = 0 mmap(NULL, >>>> 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = >>>> 0x2b9d45eb4000 read(6, "# This file controls the state o"..., 4096) = 511 >>>> read(6, "", 4096) = 0 >>>> close(6) >>>> < >>>> >>>> /etc/selinux/config is identical on both systems. >>>> >>>> >>>> Anyone a clue ? >>>> >>>> Regards, >>>> Carel >>>> >>>> >>>> -----Original Message----- >>>> From: Zhi-Wei Lu [mailto:[email protected]] >>>> Sent: dinsdag 24 juni 2014 14:18 >>>> To: Werf, C.G. van der (Carel); '[email protected]' >>>> Subject: RE: yum segfaulting >>>> >>>> I had similar problem before, someone changed the stock system libz.so >>>> with a newer version libz.so, which yum didn't like it! >>>> >>>> Zhi-Wei Lu >>>> IET-CR-Network Operations Center >>>> University of California, Davis >>>> (530) 752-0155 >>>> >>>> -----Original Message----- >>>> From: [email protected] >>>> [mailto:[email protected]] On Behalf Of >>>> Werf, C.G. van der (Carel) >>>> Sent: Tuesday, June 24, 2014 12:23 AM >>>> To: '[email protected]' >>>> Subject: yum segfaulting >>>> >>>> Hi, >>>> >>>> I have two identical SL 5.3 fileservers, who function as a DRBD-pair. >>>> One of them was recently completely replaced with identical hardware, so I >>>> had to image the old one, and install OS-image on "new" server. >>>> >>>> But now, when I run yum on the new server, it returns a segmentation fault >>>> (even a simple: # yum --help). >>>> >>>> Googling this, a lot of pages hint for a memory error. But, running a >>>> memtest did not show any error. >>>> >>>> So far, only yum returns the segmentation fault. >>>> >>>> Does anyone have any clue for this ? >>>> >>>> Regards, >>>> Carel van der Werf >>> >>> -- >>> Pat Riehecky >>> >>> Scientific Linux developer >>> http://www.scientificlinux.org/ >>> >> >> >> -- >> Pat Riehecky >> >> Scientific Linux developer >> http://www.scientificlinux.org/
