We upgraded a 64 bit server from Centos 4 to 5 and encountered some strange problems. Tcsh segfaulted irregurarily and emacs gave irregurarily strange error messages about regular expressions. Both problems disappeared when a 32-bit version was installed instead of the 64-bit. Ldconfig still occasionally segfaults.
64-bit servers where Centos 5 was installed from scratch have no problems. It is like there were some sort of remnant of the previous OS, but I can't figure out where.
Strace of a 64-bit tcsh usually ends like this:
open("/usr/lib/locale/locale-archive", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=55537056, ...}) = 0 mmap(NULL, 55537056, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2aaaaaae0000 close(3) = 0 brk(0) = 0x15b30000 brk(0x15b30800) = 0x15b30000 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++
and ltrace gives:
__libc_start_main(0x405180, 1, 0x7fff89087298, 0x440b30, 0x440b20 <unfinished ...> setlocale(5, "" <unfinished ...> sbrk(0) = 0x141f1000 sbrk(2048) = 0xffffffffffffffff --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++
Does anyone have any ideas?
Erkki.Aalto@Helsinki.FI wrote:
We upgraded a 64 bit server from Centos 4 to 5 and encountered some strange problems.
I've seen this problem both for CentOS and Fedora.
An example could be:
CentOS 4.x: has foo-7.2-el4 CentOS 4.x updates: has foo-7.4-el4 CentOS 5: has foo-7.3-el5
So when you do an upgrade to CentOS 5, you don't get the el5 version as 7.3 < 7.4.
Last I did an upgrade of FC6 to F-7 I ended up with a system with non-functional yum because of some mismatching python modules...
I guess it is a problem that is not very easy to solve.
You could try with an:
# rpm -qa|fgrep el4
and look for old packages.
Mogens
Mogens Kjaer spake the following on 9/7/2007 6:15 AM:
Erkki.Aalto@Helsinki.FI wrote:
We upgraded a 64 bit server from Centos 4 to 5 and encountered some strange problems.
I've seen this problem both for CentOS and Fedora.
An example could be:
CentOS 4.x: has foo-7.2-el4 CentOS 4.x updates: has foo-7.4-el4 CentOS 5: has foo-7.3-el5
So when you do an upgrade to CentOS 5, you don't get the el5 version as 7.3 < 7.4.
Last I did an upgrade of FC6 to F-7 I ended up with a system with non-functional yum because of some mismatching python modules...
I guess it is a problem that is not very easy to solve.
You could try with an:
# rpm -qa|fgrep el4
and look for old packages.
Mogens
Or rpm -qa --last and look for packages dated before the upgrade. Everything installed at the upgrade should have the same date and near to the same time. Anything before the upgrade date is probably your problem.
From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Erkki.Aalto@Helsinki.FI
We upgraded a 64 bit server from Centos 4 to 5 and encountered some strange problems. Tcsh segfaulted irregurarily and emacs gave irregurarily strange error messages about regular expressions. Both problems disappeared when a 32-bit version was installed instead of the 64-bit. Ldconfig still occasionally segfaults.
64-bit servers where Centos 5 was installed from scratch have no problems. It is like there were some sort of remnant of the previous OS, but I can't figure out where.
Strace of a 64-bit tcsh usually ends like this:
open("/usr/lib/locale/locale-archive", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=55537056, ...}) = 0 mmap(NULL, 55537056, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2aaaaaae0000 close(3) = 0 brk(0) = 0x15b30000 brk(0x15b30800) = 0x15b30000 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++
and ltrace gives:
__libc_start_main(0x405180, 1, 0x7fff89087298, 0x440b30, 0x440b20 <unfinished ...> setlocale(5, "" <unfinished ...> sbrk(0) = 0x141f1000 sbrk(2048) = 0xffffffffffffffff --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++
Does anyone have any ideas?
Not to state the obvious, but it looks like the problem lies in the locale libraries.
Try doing an RPM audit of /usr/share/locale and /usr/lib/locale and see if there is a 4.5 compiled locale lurking down there.
If you set a particular locale within shell scripts, start there first...
-Ross
______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.
From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Ross S. W. Walker
From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Erkki.Aalto@Helsinki.FI
We upgraded a 64 bit server from Centos 4 to 5 and encountered some strange problems. Tcsh segfaulted irregurarily and emacs gave irregurarily strange error messages about regular expressions. Both problems disappeared when a 32-bit version was installed instead of
the 64-bit.
Ldconfig still occasionally segfaults.
64-bit servers where Centos 5 was installed from scratch have no problems. It is like there were some sort of remnant of the previous OS, but I can't figure out where.
Strace of a 64-bit tcsh usually ends like this:
open("/usr/lib/locale/locale-archive", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=55537056, ...}) = 0 mmap(NULL, 55537056, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2aaaaaae0000 close(3) = 0 brk(0) = 0x15b30000 brk(0x15b30800) = 0x15b30000 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++
and ltrace gives:
__libc_start_main(0x405180, 1, 0x7fff89087298, 0x440b30, 0x440b20 <unfinished ...> setlocale(5, "" <unfinished ...> sbrk(0) =
0x141f1000
sbrk(2048) = 0xffffffffffffffff --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++
Does anyone have any ideas?
Not to state the obvious, but it looks like the problem lies in the locale libraries.
Try doing an RPM audit of /usr/share/locale and /usr/lib/locale and see if there is a 4.5 compiled locale lurking down there.
If you set a particular locale within shell scripts, start there first...
Let me reply to my own post that it might be a version mismatch with glibc-common between 4 and 5.
-Ross
______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.
-
Erkki.Aalto＠Helsinki.FI -
Mogens Kjaer -
Ross S. W. Walker -
Scott Silva