Bug 23012 - RH7 update to glibc 2.2 breaks IBM Java 1.1.8 JDK
Summary: RH7 update to glibc 2.2 breaks IBM Java 1.1.8 JDK
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc   
(Show other bugs)
Version: 7.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-12-29 22:57 UTC by Need Real Name
Modified: 2016-11-24 15:17 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-01-03 08:06:21 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2001:001 high SHIPPED_LIVE : glibc file read or write access local vulnerability 2001-01-11 05:00:00 UTC

Description Need Real Name 2000-12-29 22:57:26 UTC
After I upgraded to the 19-Dec-2000 glibc 2.2, my IBM Java 1.1.8 reports
a segmentation violation SIGSEGV on startup. Was working fine just before
Looks like this was fixed in the 2.1.xx stream before.

Comment 1 Robson Miranda 2000-12-31 12:33:22 UTC
This seems to be a bug in locale handling, as unsetting LANG it works fine.

Comment 2 Robson Miranda 2000-12-31 12:33:35 UTC
This seems to be a bug in locale handling. If you clear LANG enveronment variable, it works fine.

Comment 3 Jakub Jelinek 2001-01-02 14:49:25 UTC
Yes, but a locale handling bug in IBM Java.
libjava.so's java_lang_System_initProperties function does approximately
(don't have source, so this is just what I saw under debugger):
char *p = setlocale(LC_CTYPE, ""), *q;
setlocale(LC_ALL, p);
q = strchr(p, '_');
At least according to my reading of
this is wrong:
     The string returned by setlocale() is such that a subsequent call with that string and its associated category will
     restore that part of the program's locale. The string returned must not be modified by the program, but may be
     overwritten by a subsequent call to setlocale().
(last sentence does not speak about setlocale with the same category).
I'll see what I can do here (either prepare a glibc patch that it will use
the same string in this case or talk to IBM).

Comment 4 Alessandro Suardi 2001-01-03 01:29:23 UTC
Hopefully a glibc patch - IBM 1.1.8 is what Oracle 8.1.x uses for most things
and it now bombs on installing 817...

Comment 5 Jakub Jelinek 2001-01-03 08:06:18 UTC
Nope, see http://sources.redhat.com/ml/libc-hacker/2001-01/msg00002.htmlhttp://sources.redhat.com/ml/libc-hacker/2001-01/msg00002.html
and the following thread.
So, I'm going to mail the IBM Linux Java newsgroup today, unless
you tell me better contacts within IBM.
I can try to hack up a workaround LD_PRELOAD library for the time
being but IBM JDK should be fixed ASAP (apparently the code has
2 different bugs, not only one, but only one causes it not to work
with glibc-2.2-9 (and the upcoming glibc 2.2.1 release)) or put one
of the patches into glibc errata rpms (but that would only delay
breakage with later glibc releases (and other distributions)).

Comment 6 Jakub Jelinek 2001-01-11 22:54:47 UTC
I've included temporary workaround for this into our glibc, just
stay assured that it will break on all other distributions with
glibc-2.2 and above.

Comment 7 Alessandro Suardi 2001-01-19 00:12:13 UTC
Just to confirm that the w/a works in case of the Oracle 817 installer...
By the time newer glibc is out I hope to be on Oracle 90x :)

Comment 8 Jeff Rush 2004-04-08 10:27:16 UTC
Thanks for finding and providing a solution to this problem.  As of
April 2004, IBM is _still_ shipping the broken version as their free
Linux download (DB2 Connection Personal Edition) and with your hint re
LANG I was, after two days, able to install onto Fedora the DB2
software using IBM's Java-based DB2 installer.  Whew!

I just wanted to add to the historical record for those who stumble
upon this issue after me.

Note You need to log in before you can comment on or make changes to this bug.