all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* 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-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

* 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 16:51 ` Dan Nicolaescu
@ 2008-02-07  0:44   ` Richard Stallman
  0 siblings, 0 replies; 13+ messages in thread
From: Richard Stallman @ 2008-02-07  0:44 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: emacs-devel

    Have you tried building after doing a "make distclean"?

I tried that just now, but it failed the same way.




^ 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

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