Red Hat Bugzilla – Full Text Bug Listing
|Summary:||RedHat GLIBC patch broken|
|Product:||Red Hat Enterprise Linux 3||Reporter:||Jason L. Froebe <jfroebe>|
|Component:||glibc||Assignee:||Jakub Jelinek <jakub>|
|Status:||CLOSED RAWHIDE||QA Contact:||Brian Brock <bbrock>|
|Fixed In Version:||2.3.2-31||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2003-08-26 15:07:23 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Jason L. Froebe 2003-08-24 14:29:23 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686) Gecko/20030721 Galeon/1.3.5 Description of problem: Hi, Sybase ASE does not run on RedHat Linux 9 or RedHat Enterprise 3.0 beta. This is due to a decision made by RedHat to implement a poorly thought out plan to force developers to write better code by incorporating a "fix" into the glibc. While RedHat's intentions may have been noble, RedHat's decision to place it within the glibc is flawed. This patch incorrectly decides that ASE is broken (it is not). =================== The patch is named glibc-redhat.patch. There are many patches in that file; in the 2.3.2 version, the one that causes the issue has a header line that starts with: +++ glibc-2.3.2-redhat/elf/rtld.c 28 Mar 2003 23:20:05 -0000 1.85 If that version has changed in more recent releases, you should still be able to check the patch for the literal string: "Incorrectly built binary which accesses errno, h_errno or _res directly. Needs to be fixed.\n" =================== We are tracking this under Sybase # 326398. related RedHat bug# 90002: binary compatibility for '_res' broken in glibc 2.3.x. Sybase is in contact with RedHat, however, RedHat needs to know the impact that RedHat's decisions make on their customers. Thanks, Version-Release number of selected component (if applicable): glibc 2.3* How reproducible: Always Steps to Reproduce: 1. run dataserver -v Actual Results: infinite loop of signal 11s Expected Results: produces version information Additional info: RedHat made a poor decision to patch the glibc. the patch needs to be removed
Comment 1 Jakub Jelinek 2003-08-24 14:41:11 EDT
If they only use _res@GLIBC_2.0, then just upgrade to glibc-2.3.2-64 or later (__res_state was introduced in glibc 2.2, so any glibc 2.1 built binary/library can reference that symbol even if not doing undefined behaviour things). If they use errno@GLIBC_2.0 or h_errno@GLIBC_2.0, then the bug is on their side (__errno_location and __h_errno_location were introduced together with symbol versioning). FYI this is not something Red Hat has introduced in our glibc patches, the only thing the patch does is attempt to run binaries using those symbols and warn about them at the same time. Stock glibc simply wouldn't start those programs at all.
Comment 2 Jason L. Froebe 2003-08-24 14:55:38 EDT
Hi Jakob, Umm... actually if we rebuild the rpm from the SRPM provided by RedHat and modifying the SPEC file to omit the patch, then ASE runs fine. So your conclusion that the problem is not the RedHat GLIBC patch is flawed. I believe it would be beneficial that you talk with Sybase engineering (RedHat is a partner of Sybase). It would be in the best interest to both RedHat and Sybase to get this resolved. This issue is being tracked with Sybase case# 10949411 and CR 326398. I will have the appropriate people within Sybase Engineering to contact you. Please let me know if anyone else besides you within RedHat needs to be included in the contact list. thanks Jason
Comment 3 Jakub Jelinek 2003-08-24 15:08:43 EDT
Rebuild with --target i686 or just rebuild? That makes very big difference (.i386.rpm has no NPTL).
Comment 4 Jason L. Froebe 2003-08-24 15:14:54 EDT
Ah but the i386 build version of the GLIBC is broken (I do not have the bugzilla # but I'll request that it be provided). The 686 version is required. I've sent you and Sybase Engineering an email to start the communication between the two partners. The email addresses of the people involved in the email shouldn't be placed here for the public to see unless those individuals approve.
Comment 5 Jason L. Froebe 2003-08-24 15:27:49 EDT
For the sake of documentation (other customers of RedHat & Sybase may be running into this) Linux Kernel 2.4.20 GLIBC 2.3.2 Adaptive Server Enterprise/184.108.40.206/EBF 10980 ESD#1/P/Linux Intel/Linux 2.4.18-18.7.xsmp i686/rel12503/1919/32-bit/OPT/Mon Mar 24 20:49:12 2003 00:00000:00001:2003/07/11 10:33:49.29 serverThe logical pagesize of the server is 2 Kb. 00:00000:00001:2003/07/11 10:33:49.35 kernel current process (0x50005) infected with 11 00:00000:00001:2003/07/11 10:33:49.35 kernel ************************************ 00:00000:00001:2003/07/11 10:33:49.36 kernel curdb = 1 pstat = 0x4000 lasterror = 0 00:00000:00001:2003/07/11 10:33:49.37 kernel preverror = 0 transtate = 1 00:00000:00001:2003/07/11 10:33:49.37 kernel current process (0x50005) infected with 11 00:00000:00001:2003/07/11 10:33:49.37 kernel ************************************ 00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x8669a79 ucbacktrace+0x89(0x0,0x1,0x8d7d76c,0xb,0x404a41a4) 00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x810fb11 terminate_process+0x1b1(0x0,0xffffffff,0xb,0x40074bd8,0x405ffbe0) 00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x8682474 kisignal+0x48 *** ECM UPDATE 07/11/03 08:56:00 email@example.com Action Type: Note by Cust (0xb,0x404a3020,0x404a30a0,0x401ecb20,0x0) 00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x4006fee7 init_dummy+0x37765b43(0xb,0x404a3020,0x404a30a0,0xb,0x0) 00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x400dd620 init_dummy+0x377d327c(0x404a3a7c,0x8b03a0a,0x404a3ffc,0x404a3e12,0x0) 00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x4011f4b4 init_dummy+0x37815110(0x404a3e12,0x1d2,0x8b03a0a,0x404a3ff0,0x8d7d76c) 00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x867b4b6 kcierrfmt+0x2da(0x404a3de4,0x2e65d,0x404a3ff0,0x4,0x404a3de4) 00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x867b5f8 kcierrlog+0x34(0x2e65d,0x0,0x1e,0x40b29a40,0x2e65c) 00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x8110170 terminate_process+0x810(0x0,0xffffffff,0xb,0x40074bd8,0x405ffbe0) 00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x8682474 kisignal+0x48(0xb,0x404a41b8,0x404a4238,0x401ecb20,0x0) 00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x4006fee7 init_dummy+0x37765b43(0xb,0x404a41b8,0x404a4238,0xb,0x0) 00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x400dd620 init_dummy+0x377d327c(0x404a4c04,0x8992f4c,0x404a4cf4,0x404a59b4,0x0) 00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x40119edc init_dummy+0x3780fb38 *** ECM UPDATE 07/11/03 08:57:00 firstname.lastname@example.org Action Type: Note by Cust (0x404a59b4,0x8992f4c,0x404a4cec,0x86b7a96,0x8d7d76c) 00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x401073dd init_dummy+0x377fd039(0x404a59b4,0x8992f4c,0x88,0x404a5390,0x8d7d76c) 00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x8158762 ex_stuffp+0x2f6(0x1,0x404a5bb4,0x404a59b4,0x88,0x404a5390) 00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x8155229 ex_doprint+0xa2d(0xd78,0xa,0x1,0x404a5e08,0x8d7d76c) 00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x81547f1 ex_print+0x99(0xd78,0xa,0x1,0x404a5e08,0x8d7d76c) 00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x81583c5 ex_callprint+0x15d(0xd78,0xa,0x1,0x6,0x40a59bf6) 00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x8336a99 upgd_upgrade_db+0x71(0x40a59940,0x1,0x8d7d76c,0x8d90fe0,0x402046c0) 00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x81138d3 dsinit__bootstrap_masterdev+0x63(0x5,0xdb5,0x2,0x0,0x0) 00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x810e102 dsinit+0x5b6(0x0,0x404a6180,0x895eed31,0x0,0x0) 00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x86a1984 kpexit(0x0,0x0,0x0,0x40446100,0x6) 00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x895eed31 init_dummy+0x80ce498d(0x0,0x40446100,0x6,0x1,0x5374616b) 00:00000:00001:2003/07/11 10:33:49.39 kernel end of stack trace, spid 1, kpid 327685, suid 1 This can be reproduced on RedHat Linux 9 or RedHat Enterprise 3 series (beta)
Comment 6 Jason L. Froebe 2003-08-25 11:16:59 EDT
corresponding RedHat case # RH 26221
Comment 7 Jakub Jelinek 2003-08-26 15:07:23 EDT
Jim.Kuo@sybase.com wrote: > You are right about glibc < > 2.3.2-31 loading /lib/libpthread.so.0. > > > Our engineer just used the following packages from rawhide > (http://ftp.redhat.com/pub/redhat/linux/rawhide/i386/RedHat/RPMS/: > glibc-2.3.2-71.i686.rpm > glibc-common-2.3.2-71.i386.rpm > glibc-devel-2.3.2-71.i386.rpm > tzdata-2003a-2.noarch.rpm > > And installed it onto a computer running RedHat 9. > > With these new RPMs, ASE runs fine.