unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* dump (temacs) fails, core in alloc.c
@ 2009-11-09 17:59 Jan Djärv
  2009-11-09 18:36 ` Jan Djärv
  0 siblings, 1 reply; 12+ messages in thread
From: Jan Djärv @ 2009-11-09 17:59 UTC (permalink / raw)
  To: Emacs-Devel

Hello.

Can anybody in the know fix this? temacs -batch -l loadup dump
gets a segmentation violation at alloc.c:

Program received signal SIGSEGV, Segmentation fault.
0x00000000005c2b23 in compact_small_strings () at alloc.c:2264
2264	  for (b = tb->next; b; b = next)
(gdb) p b
$1 = (struct sblock *) 0x0
(gdb) p tb
$2 = (struct sblock *) 0x0
(gdb) p oldest_sblock
$3 = (struct sblock *) 0x0

	Jan D.





^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: dump (temacs) fails, core in alloc.c
  2009-11-09 17:59 dump (temacs) fails, core in alloc.c Jan Djärv
@ 2009-11-09 18:36 ` Jan Djärv
  2009-11-09 19:12   ` Dan Nicolaescu
  0 siblings, 1 reply; 12+ messages in thread
From: Jan Djärv @ 2009-11-09 18:36 UTC (permalink / raw)
  To: Emacs-Devel


Never mind, a bootstrap was required.

	Jan D.

Jan Djärv skrev:
> Hello.
> 
> Can anybody in the know fix this? temacs -batch -l loadup dump
> gets a segmentation violation at alloc.c:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000000005c2b23 in compact_small_strings () at alloc.c:2264
> 2264      for (b = tb->next; b; b = next)
> (gdb) p b
> $1 = (struct sblock *) 0x0
> (gdb) p tb
> $2 = (struct sblock *) 0x0
> (gdb) p oldest_sblock
> $3 = (struct sblock *) 0x0
> 
>     Jan D.
> 
> 





^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: dump (temacs) fails, core in alloc.c
  2009-11-09 18:36 ` Jan Djärv
@ 2009-11-09 19:12   ` Dan Nicolaescu
  2009-11-09 19:42     ` Eli Zaretskii
  0 siblings, 1 reply; 12+ messages in thread
From: Dan Nicolaescu @ 2009-11-09 19:12 UTC (permalink / raw)
  To: Jan Djärv; +Cc: Emacs-Devel

Jan Djärv <jan.h.d@swipnet.se> writes:

  > Never mind, a bootstrap was required.

lisp.h is not consistenly listed as a dependency in Makefile (not sure why).
So it's probably Stefan's lisp.h change that probably tripped you...

  > 	Jan D.
  > 
  > Jan Djärv skrev:
  > > Hello.
  > >
  > > Can anybody in the know fix this? temacs -batch -l loadup dump
  > > gets a segmentation violation at alloc.c:
  > >
  > > Program received signal SIGSEGV, Segmentation fault.
  > > 0x00000000005c2b23 in compact_small_strings () at alloc.c:2264
  > > 2264      for (b = tb->next; b; b = next)
  > > (gdb) p b
  > > $1 = (struct sblock *) 0x0
  > > (gdb) p tb
  > > $2 = (struct sblock *) 0x0
  > > (gdb) p oldest_sblock
  > > $3 = (struct sblock *) 0x0
  > >
  > >     Jan D.
  > >
  > >




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: dump (temacs) fails, core in alloc.c
  2009-11-09 19:12   ` Dan Nicolaescu
@ 2009-11-09 19:42     ` Eli Zaretskii
  2009-11-09 20:37       ` Dan Nicolaescu
  0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2009-11-09 19:42 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: jan.h.d, emacs-devel

> Date: Mon, 9 Nov 2009 11:12:05 -0800 (PST)
> From: Dan Nicolaescu <dann@ics.uci.edu>
> Cc: Emacs-Devel <emacs-devel@gnu.org>
> 
> lisp.h is not consistenly listed as a dependency in Makefile (not sure why).

Richard used to be opposed to that, to avoid recompiling everything
whenever some small part or even comment in lisp.h changes.  Not sure
if this is still a valid concern, what with today's compilation speed.

> So it's probably Stefan's lisp.h change that probably tripped you...

I always manually delete all *.o files when there's a significant
change in lisp.h.




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: dump (temacs) fails, core in alloc.c
  2009-11-09 19:42     ` Eli Zaretskii
@ 2009-11-09 20:37       ` Dan Nicolaescu
  2009-11-09 22:02         ` Stefan Monnier
  2009-11-10 14:56         ` dump (temacs) fails, core in alloc.c Richard Stallman
  0 siblings, 2 replies; 12+ messages in thread
From: Dan Nicolaescu @ 2009-11-09 20:37 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: jan.h.d, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

  > > Date: Mon, 9 Nov 2009 11:12:05 -0800 (PST)
  > > From: Dan Nicolaescu <dann@ics.uci.edu>
  > > Cc: Emacs-Devel <emacs-devel@gnu.org>
  > > 
  > > lisp.h is not consistenly listed as a dependency in Makefile (not sure why).
  > 
  > Richard used to be opposed to that, to avoid recompiling everything
  > whenever some small part or even comment in lisp.h changes.  Not sure
  > if this is still a valid concern, what with today's compilation speed.
  > 
  > > So it's probably Stefan's lisp.h change that probably tripped you...
  > 
  > I always manually delete all *.o files when there's a significant
  > change in lisp.h.

Tools are much more reliable than humans, compilation speed for emacs is
not a big concern anymore, so IMHO lisp.h should be added as a
dependency.




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: dump (temacs) fails, core in alloc.c
  2009-11-09 20:37       ` Dan Nicolaescu
@ 2009-11-09 22:02         ` Stefan Monnier
  2009-11-09 23:15           ` Dan Nicolaescu
  2009-11-10  7:07           ` Jan D.
  2009-11-10 14:56         ` dump (temacs) fails, core in alloc.c Richard Stallman
  1 sibling, 2 replies; 12+ messages in thread
From: Stefan Monnier @ 2009-11-09 22:02 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: Eli Zaretskii, jan.h.d, emacs-devel

> Tools are much more reliable than humans, compilation speed for emacs is
> not a big concern anymore, so IMHO lisp.h should be added as a
> dependency.

Fine by me,


        Stefan "who uses a `make depend' scheme and hence gets those
                extra dependencies anyway"




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: dump (temacs) fails, core in alloc.c
  2009-11-09 22:02         ` Stefan Monnier
@ 2009-11-09 23:15           ` Dan Nicolaescu
  2009-11-10 14:01             ` Stefan Monnier
  2009-11-10  7:07           ` Jan D.
  1 sibling, 1 reply; 12+ messages in thread
From: Dan Nicolaescu @ 2009-11-09 23:15 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Eli Zaretskii, jan.h.d, emacs-devel

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

  > > Tools are much more reliable than humans, compilation speed for emacs is
  > > not a big concern anymore, so IMHO lisp.h should be added as a
  > > dependency.
  > 
  > Fine by me,

If nobody beats me to it (but hopefully somebody will), I'll do it after
I clear my current patch backlog (63 files changed...)

  >         Stefan "who uses a `make depend' scheme and hence gets those
  >                 extra dependencies anyway"

That's TRTD, but ...
Will Stefan's "magic tree that implements all kinds of interesting
stuff" appear in BZR once we make the switch?




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: dump (temacs) fails, core in alloc.c
  2009-11-09 22:02         ` Stefan Monnier
  2009-11-09 23:15           ` Dan Nicolaescu
@ 2009-11-10  7:07           ` Jan D.
  2009-11-10 14:02             ` Stefan Monnier
  1 sibling, 1 reply; 12+ messages in thread
From: Jan D. @ 2009-11-10  7:07 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Eli Zaretskii, Dan Nicolaescu, emacs-devel

On 2009-11-09 23:02, Stefan Monnier wrote:
>> Tools are much more reliable than humans, compilation speed for emacs is
>> not a big concern anymore, so IMHO lisp.h should be added as a
>> dependency.
>
> Fine by me,
>
>
>          Stefan "who uses a `make depend' scheme and hence gets those
>                  extra dependencies anyway"

How about detecting if we are using gcc and generate dependencies on the 
fly while compiling the first time?  I see many packages that does so. 
Would such a change be OK?

	Jan D.







^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: dump (temacs) fails, core in alloc.c
  2009-11-09 23:15           ` Dan Nicolaescu
@ 2009-11-10 14:01             ` Stefan Monnier
  0 siblings, 0 replies; 12+ messages in thread
From: Stefan Monnier @ 2009-11-10 14:01 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: Eli Zaretskii, jan.h.d, emacs-devel

>> Stefan "who uses a `make depend' scheme and hence gets those
>> extra dependencies anyway"
> That's TRTD, but ...
> Will Stefan's "magic tree that implements all kinds of interesting
> stuff" appear in BZR once we make the switch?

That tree is not secret.  If people want it, I can make it accessible
publically, but really: there's a reason why those patches aren't in the
trunk yet.  Sometimes that reason is just that I haven't gotten to it
yet, but for more important changes (e.g., "make depend", or
multiple-inheritance in keymaps) the reason is that the implementation
I have is not good enough for the trunk.


        Stefan




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: dump (temacs) fails, core in alloc.c
  2009-11-10  7:07           ` Jan D.
@ 2009-11-10 14:02             ` Stefan Monnier
  2009-11-14 15:24               ` Gcc-generated dependencise. (Was: Re: dump (temacs) fails, core in alloc.c) Jan Djärv
  0 siblings, 1 reply; 12+ messages in thread
From: Stefan Monnier @ 2009-11-10 14:02 UTC (permalink / raw)
  To: Jan D.; +Cc: Eli Zaretskii, Dan Nicolaescu, emacs-devel

> How about detecting if we are using gcc and generate dependencies on the fly
> while compiling the first time?  I see many packages that does so. Would
> such a change be OK?

That would be good, yes.  As long as it doesn't break builds on non-gcc
and non-gmake systems.


        Stefan




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: dump (temacs) fails, core in alloc.c
  2009-11-09 20:37       ` Dan Nicolaescu
  2009-11-09 22:02         ` Stefan Monnier
@ 2009-11-10 14:56         ` Richard Stallman
  1 sibling, 0 replies; 12+ messages in thread
From: Richard Stallman @ 2009-11-10 14:56 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: eliz, jan.h.d, emacs-devel

In the past, recompiling everything due to a change in lisp.h was
extremely painful.  Removing that dependency was really important.

What to do today is up to the current maintainers.




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Gcc-generated dependencise. (Was: Re: dump (temacs) fails, core in alloc.c)
  2009-11-10 14:02             ` Stefan Monnier
@ 2009-11-14 15:24               ` Jan Djärv
  0 siblings, 0 replies; 12+ messages in thread
From: Jan Djärv @ 2009-11-14 15:24 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Eli Zaretskii, Dan Nicolaescu, emacs-devel

Stefan Monnier skrev:
>> How about detecting if we are using gcc and generate dependencies on the fly
>> while compiling the first time?  I see many packages that does so. Would
>> such a change be OK?
> 
> That would be good, yes.  As long as it doesn't break builds on non-gcc
> and non-gmake systems.
> 

I have checked in dependency generation on the fly for src.  Configure checks 
for gcc -MMD -MF and GNU Make and if not explicitly disabled with 
--disable-autodepend, dependencies are then generated when files are compiled.

	Jan D.




^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2009-11-14 15:24 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-11-09 17:59 dump (temacs) fails, core in alloc.c Jan Djärv
2009-11-09 18:36 ` Jan Djärv
2009-11-09 19:12   ` Dan Nicolaescu
2009-11-09 19:42     ` Eli Zaretskii
2009-11-09 20:37       ` Dan Nicolaescu
2009-11-09 22:02         ` Stefan Monnier
2009-11-09 23:15           ` Dan Nicolaescu
2009-11-10 14:01             ` Stefan Monnier
2009-11-10  7:07           ` Jan D.
2009-11-10 14:02             ` Stefan Monnier
2009-11-14 15:24               ` Gcc-generated dependencise. (Was: Re: dump (temacs) fails, core in alloc.c) Jan Djärv
2009-11-10 14:56         ` dump (temacs) fails, core in alloc.c 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).