Bug 61692

Summary:	New glibc stops xemacs and dmalloc from building
Product:	[Retired] Red Hat Linux	Reporter:	Trond Eivind Glomsrxd <teg>
Component:	glibc	Assignee:	Jakub Jelinek <jakub>
Status:	CLOSED RAWHIDE	QA Contact:	Brian Brock <bbrock>
Severity:	high	Docs Contact:
Priority:	medium
Version:	7.3	CC:	fweimer
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2002-03-27 10:15:43 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	61590

Description Trond Eivind Glomsrxd 2002-03-22 23:11:49 UTC

Xemacs and dmalloc both build with the currently released version of glibc
(2.2.4-19.3), but fail with glibc-2.2.5-27. Dmalloc grows to consume all memory
and is killed, xemacs gets internal failures of it.

Comment 1 Jakub Jelinek 2002-03-25 19:03:45 UTC

Can you please mention details about xemacs failures (ie. what should I run
to reproduce it)?

Comment 2 Trond Eivind Glomsrxd 2002-03-25 19:38:03 UTC

Just grab the xemacs package in the 7.3-beta and do a "rpm --rebuild".

Comment 3 Jakub Jelinek 2002-03-25 22:36:56 UTC

In the xemacs case, what leads you to believe it is an glibc bug and not
something else?
xemacs crashes for me both if I run:
./xemacs -batch -vanilla -f list-load-path-shadows
l/ld-linux.so.2 --library-path l/ ./xemacs -batch -vanilla -f list-load-path-shadows
/lib/ld-linux.so.2 --library-path /lib/ ./xemacs -batch -vanilla -f list-load-path-shadows
(l/ is subdirectory populated with glibc-2.2.4-19.3 libraries).

Comment 4 Trond Eivind Glomsrxd 2002-03-25 23:13:28 UTC

I installed the public beta, and it failed during build. I downgraded glibc to
the release version, and it built fine. No other changes made.

Comment 5 Jakub Jelinek 2002-03-26 14:13:37 UTC

Trond, could you work on debugging this too?
It is very likely this is an xemacs bug (I already found one thinko in
unexelf.c), although it is triggered by glibc change.
So far I know that:
./temacs -nd -batch -l /usr/src/redhat/BUILD/xemacs-21.4.6/src/../lisp/loadup.el dump
when run with old glibc creates a working xemacs binary (which works with
whatever glibc is tried), while running the above command against new glibc
creates somewhat smaller xemacs binary which crashes (it doesn't matter at
all what glibc was temacs binary compiled against).
The bug I found so far is that unexelf.c doesn't clear NEW_SECTION_H(0) record,
so it can contain total garbage.

Comment 6 Jakub Jelinek 2002-03-27 10:15:38 UTC

I've backed out new malloc from Hampton glibc, though this will need to be
debugged for Milan. The huge size difference between xemacs built with
glibc-2.2.5-27 (4672454) and glibc-2.2.5-29 (5042174) shows the new malloc
being superior to the old one wrt. fragmentation, just xemacs is somewhere
relying on something it should not :(. IMHO this unexelf thingie is
broken by design.

Comment 7 Jakub Jelinek 2002-04-04 10:40:13 UTC

Will need to be solved for Milan...