* unexec problem
@ 2008-02-04 17:22 Richard Stallman
2008-02-04 21:23 ` Chong Yidong
2008-02-06 16:51 ` Dan Nicolaescu
0 siblings, 2 replies; 13+ messages in thread
From: Richard Stallman @ 2008-02-04 17:22 UTC (permalink / raw)
To: emacs-devel
When I try to bootstrap, bootstrap-emacs crashes
in the first call to malloc. Experience shows this is
usually due to a bug in the unexec mechanism.
However, unexelf.c is unchanged from Emacs 22.
Since this sort of thing is a big pain to debug,
does anyone have any clues?
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: unexec problem
2008-02-04 17:22 unexec problem Richard Stallman
@ 2008-02-04 21:23 ` Chong Yidong
2008-02-05 8:04 ` Richard Stallman
2008-02-06 16:51 ` Dan Nicolaescu
1 sibling, 1 reply; 13+ messages in thread
From: Chong Yidong @ 2008-02-04 21:23 UTC (permalink / raw)
To: rms; +Cc: emacs-devel
Richard Stallman <rms@gnu.org> writes:
> When I try to bootstrap, bootstrap-emacs crashes
> in the first call to malloc. Experience shows this is
> usually due to a bug in the unexec mechanism.
> However, unexelf.c is unchanged from Emacs 22.
>
> Since this sort of thing is a big pain to debug,
> does anyone have any clues?
Is this on the trunk?
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: unexec problem
2008-02-04 21:23 ` Chong Yidong
@ 2008-02-05 8:04 ` Richard Stallman
2008-02-05 20:06 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Richard Stallman @ 2008-02-05 8:04 UTC (permalink / raw)
To: Chong Yidong; +Cc: emacs-devel
> When I try to bootstrap, bootstrap-emacs crashes
> in the first call to malloc. Experience shows this is
> usually due to a bug in the unexec mechanism.
> However, unexelf.c is unchanged from Emacs 22.
>
> Since this sort of thing is a big pain to debug,
> does anyone have any clues?
Is this on the trunk?
Yes. And it worked a week ago.
I think the unicode merge broke it.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: unexec problem
2008-02-05 8:04 ` Richard Stallman
@ 2008-02-05 20:06 ` Eli Zaretskii
2008-02-06 16:12 ` Richard Stallman
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2008-02-05 20:06 UTC (permalink / raw)
To: rms; +Cc: cyd, emacs-devel
> From: Richard Stallman <rms@gnu.org>
> Date: Tue, 05 Feb 2008 03:04:25 -0500
> Cc: emacs-devel@gnu.org
>
> > When I try to bootstrap, bootstrap-emacs crashes
> > in the first call to malloc. Experience shows this is
> > usually due to a bug in the unexec mechanism.
> > However, unexelf.c is unchanged from Emacs 22.
> >
> > Since this sort of thing is a big pain to debug,
> > does anyone have any clues?
>
> Is this on the trunk?
>
> Yes. And it worked a week ago.
> I think the unicode merge broke it.
Probably.
How about running the bootstrap temacs (the one that is dumped to
produce bootstrap-emacs) under GDB with a breakpoint in malloc, and
recording all calls to malloc with their callers? Then you could
compare that with a similar run for a pre-merge CVS, and look for some
callers that could potentially lead to corruption of the malloc chain
the the dumped executable.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: unexec problem
2008-02-05 20:06 ` Eli Zaretskii
@ 2008-02-06 16:12 ` Richard Stallman
2008-02-06 19:26 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Richard Stallman @ 2008-02-06 16:12 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: cyd, emacs-devel
How about running the bootstrap temacs (the one that is dumped to
produce bootstrap-emacs) under GDB with a breakpoint in malloc, and
recording all calls to malloc with their callers?
I don't know how to do that. Can you tell me how?
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: unexec problem
2008-02-06 16:12 ` Richard Stallman
@ 2008-02-06 19:26 ` Eli Zaretskii
2008-02-08 4:15 ` Richard Stallman
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2008-02-06 19:26 UTC (permalink / raw)
To: rms; +Cc: emacs-devel
> From: Richard Stallman <rms@gnu.org>
> CC: cyd@stupidchicken.com, emacs-devel@gnu.org
> Date: Wed, 06 Feb 2008 11:12:02 -0500
>
> How about running the bootstrap temacs (the one that is dumped to
> produce bootstrap-emacs) under GDB with a breakpoint in malloc, and
> recording all calls to malloc with their callers?
>
> I don't know how to do that. Can you tell me how?
Something like this:
cd src
gdb ./temacs
.....
(gdb) set logging on
(gdb) break malloc
(gdb) commands
> bt
> continue
> end
(gdb) run --batch --load loadup bootstrap
Then, when temacs exits, you will have all the hits of this
breakpoint, together with the backtrace of each one of them, in the
file gdb.txt. (You can change the name of the file with the command
"set logging file FOO".)
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: unexec problem
2008-02-06 19:26 ` Eli Zaretskii
@ 2008-02-08 4:15 ` Richard Stallman
2008-02-08 15:20 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Richard Stallman @ 2008-02-08 4:15 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
cd src
gdb ./temacs
.....
(gdb) set logging on
(gdb) break malloc
(gdb) commands
> bt
> continue
> end
(gdb) run --batch --load loadup bootstrap
I tried that. After it had run for several hours and produced 190 meg
of data, I killed it. I deleted the file because I can't possibly
see any pattern in such a big collection of data except by some
automated method, and we don't know what it should look for.
If you have a concrete idea for how to analyze that data,
I could run it again. Maybe overnight it would finish.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: unexec problem
2008-02-08 4:15 ` Richard Stallman
@ 2008-02-08 15:20 ` Eli Zaretskii
2008-02-10 18:42 ` Richard Stallman
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2008-02-08 15:20 UTC (permalink / raw)
To: rms; +Cc: emacs-devel
> From: Richard Stallman <rms@gnu.org>
> CC: emacs-devel@gnu.org
> Date: Thu, 07 Feb 2008 23:15:34 -0500
>
> cd src
> gdb ./temacs
> .....
> (gdb) set logging on
> (gdb) break malloc
> (gdb) commands
> > bt
> > continue
> > end
> (gdb) run --batch --load loadup bootstrap
>
> I tried that. After it had run for several hours and produced 190 meg
> of data, I killed it. I deleted the file because I can't possibly
> see any pattern in such a big collection of data except by some
> automated method, and we don't know what it should look for.
Maybe "bt N", where N is some small number, will produce a more
manageable file.
> If you have a concrete idea for how to analyze that data,
> I could run it again.
The idea was that maybe some library function we are now calling, and
that calls malloc internally, causes the corruption of the memory
allocation in the dumped Emacs. I don't know how to spot such a
function except by the method I suggested.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: unexec problem
2008-02-08 15:20 ` Eli Zaretskii
@ 2008-02-10 18:42 ` Richard Stallman
2008-02-10 19:58 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Richard Stallman @ 2008-02-10 18:42 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
The idea was that maybe some library function we are now calling, and
that calls malloc internally, causes the corruption of the memory
allocation in the dumped Emacs. I don't know how to spot such a
function except by the method I suggested.
The problem is how to find a candidate for the problem out of
thousands of backtraces of malloc calls. I don't
see how I could even try.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: unexec problem
2008-02-10 18:42 ` Richard Stallman
@ 2008-02-10 19:58 ` Eli Zaretskii
2008-02-11 13:35 ` Richard Stallman
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2008-02-10 19:58 UTC (permalink / raw)
To: rms; +Cc: emacs-devel
> From: Richard Stallman <rms@gnu.org>
> CC: emacs-devel@gnu.org
> Date: Sun, 10 Feb 2008 13:42:09 -0500
>
> The idea was that maybe some library function we are now calling, and
> that calls malloc internally, causes the corruption of the memory
> allocation in the dumped Emacs. I don't know how to spot such a
> function except by the method I suggested.
>
> The problem is how to find a candidate for the problem out of
> thousands of backtraces of malloc calls.
Does the dumped Emacs crash even if you dump it immediately after
temacs starts, without loading any of the Lisp files it loads during
loading loadup.el (by hacking it to comment out all the load
commands)? If so, perhaps the amount of calls to malloc would be much
smaller, and you could look at it.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: unexec problem
2008-02-10 19:58 ` Eli Zaretskii
@ 2008-02-11 13:35 ` Richard Stallman
0 siblings, 0 replies; 13+ messages in thread
From: Richard Stallman @ 2008-02-11 13:35 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Does the dumped Emacs crash even if you dump it immediately after
temacs starts, without loading any of the Lisp files it loads during
loading loadup.el (by hacking it to comment out all the load
commands)? If so, perhaps the amount of calls to malloc would be much
smaller, and you could look at it.
It crashes on the first call to malloc. That means the data
structures as dumped must be corrupted. But I don't know what the
data structures of malloc look like, not nowadays.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: unexec problem
2008-02-04 17:22 unexec problem Richard Stallman
2008-02-04 21:23 ` Chong Yidong
@ 2008-02-06 16:51 ` Dan Nicolaescu
2008-02-07 0:44 ` Richard Stallman
1 sibling, 1 reply; 13+ messages in thread
From: Dan Nicolaescu @ 2008-02-06 16:51 UTC (permalink / raw)
To: rms; +Cc: emacs-devel
Richard Stallman <rms@gnu.org> writes:
> When I try to bootstrap, bootstrap-emacs crashes
> in the first call to malloc. Experience shows this is
> usually due to a bug in the unexec mechanism.
> However, unexelf.c is unchanged from Emacs 22.
>
> Since this sort of thing is a big pain to debug,
> does anyone have any clues?
Have you tried building after doing a "make distclean"?
In the past I have seen weird unexec problems that went away after doing
a clean build...
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2008-02-11 13:35 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-02-04 17:22 unexec problem Richard Stallman
2008-02-04 21:23 ` Chong Yidong
2008-02-05 8:04 ` Richard Stallman
2008-02-05 20:06 ` Eli Zaretskii
2008-02-06 16:12 ` Richard Stallman
2008-02-06 19:26 ` Eli Zaretskii
2008-02-08 4:15 ` Richard Stallman
2008-02-08 15:20 ` Eli Zaretskii
2008-02-10 18:42 ` Richard Stallman
2008-02-10 19:58 ` Eli Zaretskii
2008-02-11 13:35 ` Richard Stallman
2008-02-06 16:51 ` Dan Nicolaescu
2008-02-07 0:44 ` Richard Stallman
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).