Bug 61692 - New glibc stops xemacs and dmalloc from building
Summary: New glibc stops xemacs and dmalloc from building
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 7.3
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks: 61590
TreeView+ depends on / blocked
 
Reported: 2002-03-22 23:11 UTC by Trond Eivind Glomsrxd
Modified: 2016-11-24 15:03 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2002-03-27 10:15:43 UTC
Embargoed:


Attachments (Terms of Use)

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


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