Bug 102995

Summary: RedHat GLIBC patch broken
Product: Red Hat Enterprise Linux 3 Reporter: Jason L. Froebe <jfroebe>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED RAWHIDE QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: medium    
Version: 3.0CC: tao
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Fixed In Version: 2.3.2-31 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-08-26 15:07:23 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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:

Sybase ASE does not run on RedHat Linux 9 or RedHat Enterprise 3.0

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

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.


Version-Release number of selected component (if applicable):
glibc 2.3*

How reproducible:

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
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.


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/ 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
00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x810fb11
00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x8682474 kisignal+0x48

*** ECM UPDATE 07/11/03 08:56:00 jfroebe@froebe.net Action Type: Note by Cust
00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x4006fee7
00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x400dd620
00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x4011f4b4
00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x867b4b6
00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x867b5f8
00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x8110170
00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x8682474
00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x4006fee7
00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x400dd620
00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x40119edc init_dummy+0x3780fb38

*** ECM UPDATE 07/11/03 08:57:00 jfroebe@froebe.net Action Type: Note by Cust
00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x401073dd
00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x8158762
00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x8155229
00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x81547f1
00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x81583c5
00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x8336a99
00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x81138d3
00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x810e102
00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x86a1984
00:00000:00001:2003/07/11 10:33:49.39 kernel pc 0x895eed31
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.