Bug 61692 - New glibc stops xemacs and dmalloc from building
New glibc stops xemacs and dmalloc from building
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
Blocks: 61590
  Show dependency treegraph
Reported: 2002-03-22 18:11 EST by Trond Eivind Glomsrxd
Modified: 2016-11-24 10:03 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-03-27 05:15:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Trond Eivind Glomsrxd 2002-03-22 18:11:49 EST
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 14:03:45 EST
Can you please mention details about xemacs failures (ie. what should I run
to reproduce it)?
Comment 2 Trond Eivind Glomsrxd 2002-03-25 14:38:03 EST
Just grab the xemacs package in the 7.3-beta and do a "rpm --rebuild".
Comment 3 Jakub Jelinek 2002-03-25 17:36:56 EST
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 18:13:28 EST
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 09:13:37 EST
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 05:15:38 EST
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 05:40:13 EST
Will need to be solved for Milan...

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