* dumping bug explained?
@ 2007-05-21 10:33 Richard Stallman
2007-05-21 10:53 ` Andreas Schwab
0 siblings, 1 reply; 9+ messages in thread
From: Richard Stallman @ 2007-05-21 10:33 UTC (permalink / raw)
To: emacs-devel
** coldwell@redhat.com, May 18: 22.0.99 emacs dumper (?) problem
This seems to be caused by a binary incompatible change for the malloc
implementation in glibc. The problem would occur when emacs is built
on one system and used on another. See
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239344#c60
for a possible complete explanation.
Are people sure that this is the cause of the problem?
If so, the only fix it needs is an entry in PROBLEMS.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dumping bug explained?
2007-05-21 10:33 dumping bug explained? Richard Stallman
@ 2007-05-21 10:53 ` Andreas Schwab
2007-05-21 14:15 ` Chong Yidong
0 siblings, 1 reply; 9+ messages in thread
From: Andreas Schwab @ 2007-05-21 10:53 UTC (permalink / raw)
To: rms; +Cc: emacs-devel
Richard Stallman <rms@gnu.org> writes:
> ** coldwell@redhat.com, May 18: 22.0.99 emacs dumper (?) problem
> This seems to be caused by a binary incompatible change for the malloc
> implementation in glibc. The problem would occur when emacs is built
> on one system and used on another. See
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239344#c60
> for a possible complete explanation.
>
> Are people sure that this is the cause of the problem?
There is already a patch available, see
<http://sourceware.org/ml/libc-hacker/2007-05/msg00015.html>.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dumping bug explained?
2007-05-21 10:53 ` Andreas Schwab
@ 2007-05-21 14:15 ` Chong Yidong
2007-05-21 14:19 ` Chip Coldwell
0 siblings, 1 reply; 9+ messages in thread
From: Chong Yidong @ 2007-05-21 14:15 UTC (permalink / raw)
To: Andreas Schwab; +Cc: rms, emacs-devel
Andreas Schwab <schwab@suse.de> writes:
> Richard Stallman <rms@gnu.org> writes:
>
>> ** coldwell@redhat.com, May 18: 22.0.99 emacs dumper (?) problem
>> This seems to be caused by a binary incompatible change for the malloc
>> implementation in glibc. The problem would occur when emacs is built
>> on one system and used on another. See
>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239344#c60
>> for a possible complete explanation.
>>
>> Are people sure that this is the cause of the problem?
>
> There is already a patch available, see
> <http://sourceware.org/ml/libc-hacker/2007-05/msg00015.html>.
To be precise (since RMS doesn't read URLs), this is a patch to glibc,
not Emacs. However, there will be released versions of glibc out
there with this problem, so we should still document it in PROBLEMS.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dumping bug explained?
2007-05-21 14:15 ` Chong Yidong
@ 2007-05-21 14:19 ` Chip Coldwell
2007-05-21 14:39 ` Chong Yidong
0 siblings, 1 reply; 9+ messages in thread
From: Chip Coldwell @ 2007-05-21 14:19 UTC (permalink / raw)
To: Chong Yidong; +Cc: Andreas Schwab, rms, emacs-devel
On Mon, 21 May 2007, Chong Yidong wrote:
> Andreas Schwab <schwab@suse.de> writes:
>
> > Richard Stallman <rms@gnu.org> writes:
> >
> >> ** coldwell@redhat.com, May 18: 22.0.99 emacs dumper (?) problem
> >> This seems to be caused by a binary incompatible change for the malloc
> >> implementation in glibc. The problem would occur when emacs is built
> >> on one system and used on another. See
> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239344#c60
> >> for a possible complete explanation.
> >>
> >> Are people sure that this is the cause of the problem?
> >
> > There is already a patch available, see
> > <http://sourceware.org/ml/libc-hacker/2007-05/msg00015.html>.
>
> To be precise (since RMS doesn't read URLs), this is a patch to glibc,
> not Emacs. However, there will be released versions of glibc out
> there with this problem, so we should still document it in PROBLEMS.
Jakub Jelinek and Ulrich Drepper are working on this in glibc. Jakub
explained it as follows: (text from
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239344#c60)
There are multiple bugs on the glibc side (unfortunately malloc_set_state the
way it is used by emacs makes many internal details of the malloc implementation
part of the ABI):
1) the
2007-04-30 Ulrich Drepper <drepper@redhat.com>
Jakub Jelinek <jakub@redhat.com>
[BZ #4349]
* malloc/malloc.c: Keep separate list for first blocks on the bin
lists with a given size. This helps skipping over list elements
we know won't fit in two places.
Inspired by a patch by Tomash Brechko <tomash.brechko@gmail.com>.
change affects the ABI, as if emacs is dumped with glibc before this patch
and run with glibc after this patch, the fd_nextsize/bk_nextsize pointers
are left uninitialized, but the new glibc relies on them having correct
values. This is solvable by recomputing these pointers in malloc_set_state.
2) I made an accidental commit that enabled MALLOC_DEBUG (in the
2007-05-07 Ulrich Drepper <drepper@redhat.com>
Jakub Jelinek <jakub@redhat.com>
* malloc/arena.c (heap_info): Add mprotect_size field, adjust pad.
(new_heap): Initialize mprotect_size.
(grow_heap): When growing, only mprotect from mprotect_size till
new_size if mprotect_size is smaller. When shrinking, use PROT_NONE
MMAP for __libc_enable_secure only, otherwise use MADV_DONTNEED.
check-in) and
2007-05-13 Ulrich Drepper <drepper@redhat.com>
* malloc/malloc.c [MALLOC_DEBUG]: Keep track of current maximum
number of mmaps. n_mmaps_max is the target.
* malloc/hooks.c: Likewise.
* malloc/arena.c: Likewise.
change added a field to struct malloc_save_state without bumping version number.
That together means another ABI change for malloc_save_state. We certainly
have to revert the MALLOC_DEBUG setting (that's expensive) and something
has to be done about the 05-13 change (state changing shouldn't depend on
MALLOC_DEBUG).
Chip
--
Charles M. "Chip" Coldwell
Senior Software Engineer
Red Hat, Inc
978-392-2426
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dumping bug explained?
2007-05-21 14:19 ` Chip Coldwell
@ 2007-05-21 14:39 ` Chong Yidong
2007-05-21 14:52 ` Chip Coldwell
2007-05-21 16:40 ` Ulrich Drepper
0 siblings, 2 replies; 9+ messages in thread
From: Chong Yidong @ 2007-05-21 14:39 UTC (permalink / raw)
To: Chip Coldwell
Cc: Jakub Jelinek, Andreas Schwab, emacs-devel, Ulrich Drepper, rms
Chip Coldwell <coldwell@redhat.com> writes:
>> To be precise (since RMS doesn't read URLs), this is a patch to glibc,
>> not Emacs. However, there will be released versions of glibc out
>> there with this problem, so we should still document it in PROBLEMS.
>
> Jakub Jelinek and Ulrich Drepper are working on this in glibc. Jakub
> explained it as follows: (text from
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239344#c60)
Do you know if Emacs will still need to be patched after these changes
to glibc are done?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dumping bug explained?
2007-05-21 14:39 ` Chong Yidong
@ 2007-05-21 14:52 ` Chip Coldwell
2007-05-21 16:40 ` Ulrich Drepper
1 sibling, 0 replies; 9+ messages in thread
From: Chip Coldwell @ 2007-05-21 14:52 UTC (permalink / raw)
To: Chong Yidong
Cc: Jakub Jelinek, Andreas Schwab, Ulrich Drepper, rms, emacs-devel
On Mon, 21 May 2007, Chong Yidong wrote:
> Chip Coldwell <coldwell@redhat.com> writes:
>
> >> To be precise (since RMS doesn't read URLs), this is a patch to glibc,
> >> not Emacs. However, there will be released versions of glibc out
> >> there with this problem, so we should still document it in PROBLEMS.
> >
> > Jakub Jelinek and Ulrich Drepper are working on this in glibc. Jakub
> > explained it as follows: (text from
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239344#c60)
>
> Do you know if Emacs will still need to be patched after these changes
> to glibc are done?
My understanding is that Emacs will not need to be patched after glibc
is updated.
Chip
--
Charles M. "Chip" Coldwell
Senior Software Engineer
Red Hat, Inc
978-392-2426
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dumping bug explained?
2007-05-21 14:39 ` Chong Yidong
2007-05-21 14:52 ` Chip Coldwell
@ 2007-05-21 16:40 ` Ulrich Drepper
2007-05-21 17:20 ` Chip Coldwell
2007-05-22 14:51 ` Richard Stallman
1 sibling, 2 replies; 9+ messages in thread
From: Ulrich Drepper @ 2007-05-21 16:40 UTC (permalink / raw)
To: Chong Yidong
Cc: Jakub Jelinek, Andreas Schwab, Chip Coldwell, rms, emacs-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chong Yidong wrote:
> Do you know if Emacs will still need to be patched after these changes
> to glibc are done?
Not all the symptoms described in the bug can be explained by the
changes. It might very well be that changes are needed.
In general, the use of malloc in emacs is horrific. We are now going to
work around some of problems created by the changes when it comes to
assumptions emacs makes, but there is no guarantee that we can keep this up.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFGUct42ijCOnn/RHQRAnuXAKChmJ9SwrUbeQeTmXNwwUB1RNI4ggCgxyNJ
zyTm12a0Glz8SK3Fs5/0qQU=
=DUhM
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dumping bug explained?
2007-05-21 16:40 ` Ulrich Drepper
@ 2007-05-21 17:20 ` Chip Coldwell
2007-05-22 14:51 ` Richard Stallman
1 sibling, 0 replies; 9+ messages in thread
From: Chip Coldwell @ 2007-05-21 17:20 UTC (permalink / raw)
To: Ulrich Drepper
Cc: Jakub Jelinek, Andreas Schwab, Chong Yidong, rms, emacs-devel
On Mon, 21 May 2007, Ulrich Drepper wrote:
> Chong Yidong wrote:
> > Do you know if Emacs will still need to be patched after these changes
> > to glibc are done?
>
> Not all the symptoms described in the bug can be explained by the
> changes. It might very well be that changes are needed.
I don't know if this is the behavior you are thinking about, but IIUC
this message
*** glibc detected *** emacs: malloc(): memory corruption: 0x0000000002904d10 ***
was generated by an assert failing in malloc that Jakub Jelinek
described in his libc-hacker posting containing his patch to solve
this problem thus "removes a bogus assert mp_.n_mmaps <=
mp_.n_mmaps_max." This would be the assert that would succeed if you
dumped emacs with MALLOC_MMAP_MAX_=0, right?
Chip
--
Charles M. "Chip" Coldwell
Senior Software Engineer
Red Hat, Inc
978-392-2426
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dumping bug explained?
2007-05-21 16:40 ` Ulrich Drepper
2007-05-21 17:20 ` Chip Coldwell
@ 2007-05-22 14:51 ` Richard Stallman
1 sibling, 0 replies; 9+ messages in thread
From: Richard Stallman @ 2007-05-22 14:51 UTC (permalink / raw)
To: Ulrich Drepper; +Cc: jakub, schwab, cyd, coldwell, emacs-devel
In general, the use of malloc in emacs is horrific.
Which aspects do you find particularly troublesome?
We could try to look for ways to change them.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2007-05-22 14:51 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-05-21 10:33 dumping bug explained? Richard Stallman
2007-05-21 10:53 ` Andreas Schwab
2007-05-21 14:15 ` Chong Yidong
2007-05-21 14:19 ` Chip Coldwell
2007-05-21 14:39 ` Chong Yidong
2007-05-21 14:52 ` Chip Coldwell
2007-05-21 16:40 ` Ulrich Drepper
2007-05-21 17:20 ` Chip Coldwell
2007-05-22 14:51 ` Richard Stallman
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.