all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* dump-emacs doesn't fail even if Pure Lisp storage overflows
@ 2006-01-20  7:41 Kenichi Handa
  2006-01-20 17:51 ` Stefan Monnier
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Kenichi Handa @ 2006-01-20  7:41 UTC (permalink / raw)


I've just increased BASE_PURESIZE to 1190000 because it
seems that Solaris requires more pure bytes than GNU/Linux.

But, the problem is that building of Emacs proceeds even if
this message is shown:

Pure Lisp storage overflow (approx. 1173352 bytes needed)

And, the resulting emacs behaves very strangely.

Shouldn't we stop the building by error in such a case?

---
Kenichi Handa
handa@m17n.org

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

* Re: dump-emacs doesn't fail even if Pure Lisp storage overflows
  2006-01-20  7:41 dump-emacs doesn't fail even if Pure Lisp storage overflows Kenichi Handa
@ 2006-01-20 17:51 ` Stefan Monnier
  2006-01-24 11:25   ` Kenichi Handa
  2006-01-20 22:58 ` Richard M. Stallman
  2006-01-22  0:48 ` Juri Linkov
  2 siblings, 1 reply; 9+ messages in thread
From: Stefan Monnier @ 2006-01-20 17:51 UTC (permalink / raw)
  Cc: emacs-devel

> But, the problem is that building of Emacs proceeds even if
> this message is shown:

> Pure Lisp storage overflow (approx. 1173352 bytes needed)

> And, the resulting emacs behaves very strangely.

IIRC what happens is that it doesn't do GC, other than that it should
behave normally.  It is useful for bootstrapping to be able to get an Emacs
that works well enough to byte-compile some files (which will then use less
Pure storage next time we dump them).

A pure lisp storage overflow is a serious bug that neds to be fixed, but
I don't think it's a good excuse to refuse to build an `emacs' executable.


        Stefan

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

* Re: dump-emacs doesn't fail even if Pure Lisp storage overflows
  2006-01-20  7:41 dump-emacs doesn't fail even if Pure Lisp storage overflows Kenichi Handa
  2006-01-20 17:51 ` Stefan Monnier
@ 2006-01-20 22:58 ` Richard M. Stallman
  2006-01-22  0:48 ` Juri Linkov
  2 siblings, 0 replies; 9+ messages in thread
From: Richard M. Stallman @ 2006-01-20 22:58 UTC (permalink / raw)
  Cc: emacs-devel

    Pure Lisp storage overflow (approx. 1173352 bytes needed)

    And, the resulting emacs behaves very strangely.

    Shouldn't we stop the building by error in such a case?

I don't see how that would be helpful.  The current code
is intended to show there is a problem, but also lets you debug
whatever fix you are testing.  You don't have to edit PURESIZE
and rebuild first.

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

* Re: dump-emacs doesn't fail even if Pure Lisp storage overflows
  2006-01-20  7:41 dump-emacs doesn't fail even if Pure Lisp storage overflows Kenichi Handa
  2006-01-20 17:51 ` Stefan Monnier
  2006-01-20 22:58 ` Richard M. Stallman
@ 2006-01-22  0:48 ` Juri Linkov
  2006-01-22  2:15   ` Luc Teirlinck
                     ` (2 more replies)
  2 siblings, 3 replies; 9+ messages in thread
From: Juri Linkov @ 2006-01-22  0:48 UTC (permalink / raw)
  Cc: emacs-devel

> I've just increased BASE_PURESIZE to 1190000 because it
> seems that Solaris requires more pure bytes than GNU/Linux.
>
> But, the problem is that building of Emacs proceeds even if
> this message is shown:
>
> Pure Lisp storage overflow (approx. 1173352 bytes needed)

This message is very easy to miss.  Perhaps it should be changed to allow
highlighting by one of the compile.el rules, for instance:

emacs:0:warning: Pure Lisp storage overflow (approx. 1181968 bytes needed)

> And, the resulting emacs behaves very strangely.

Due to the following condition in `Fgarbage_collect' GC gets skipped:

  if (pure_bytes_used_before_overflow)
    return Qnil;

There is a special function `check_pure_size' to print a warning.  I tried
to add it to this condition, but calling it directly from this condition
prints warning messages too often, because when GC can't be done,
Fgarbage_collect gets called repeatedly.

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

* Re: dump-emacs doesn't fail even if Pure Lisp storage overflows
  2006-01-22  0:48 ` Juri Linkov
@ 2006-01-22  2:15   ` Luc Teirlinck
  2006-01-22  3:19   ` Luc Teirlinck
  2006-01-22 17:44   ` Richard M. Stallman
  2 siblings, 0 replies; 9+ messages in thread
From: Luc Teirlinck @ 2006-01-22  2:15 UTC (permalink / raw)
  Cc: emacs-devel, handa

Juri Linkov wrote:

   > But, the problem is that building of Emacs proceeds even if
   > this message is shown:
   >
   > Pure Lisp storage overflow (approx. 1173352 bytes needed)

   This message is very easy to miss.

But when you then start Emacs you get the following difficult to miss
warning on your startup screen:

   Warning Warning  Pure space overflow  Warning Warning


   There is a special function `check_pure_size' to print a warning.  I tried
   to add it to this condition, but calling it directly from this condition
   prints warning messages too often, because when GC can't be done,
   Fgarbage_collect gets called repeatedly.

Showing it at startup should be sufficient for people to notice.
They noticed it this time: the bug got reported on emacs-pretest-bug.

Sincerely,

Luc.

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

* Re: dump-emacs doesn't fail even if Pure Lisp storage overflows
  2006-01-22  0:48 ` Juri Linkov
  2006-01-22  2:15   ` Luc Teirlinck
@ 2006-01-22  3:19   ` Luc Teirlinck
  2006-01-23  1:54     ` Juri Linkov
  2006-01-22 17:44   ` Richard M. Stallman
  2 siblings, 1 reply; 9+ messages in thread
From: Luc Teirlinck @ 2006-01-22  3:19 UTC (permalink / raw)
  Cc: emacs-devel, handa

>From my earlier reply:

   But when you then start Emacs you get the following difficult to miss
   warning on your startup screen:

      Warning Warning  Pure space overflow  Warning Warning

I should have explicitly mentioned that you only see this warning if
inhibit-splash-screen is nil (as it is by default).

Sincerely,

Luc.

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

* Re: dump-emacs doesn't fail even if Pure Lisp storage overflows
  2006-01-22  0:48 ` Juri Linkov
  2006-01-22  2:15   ` Luc Teirlinck
  2006-01-22  3:19   ` Luc Teirlinck
@ 2006-01-22 17:44   ` Richard M. Stallman
  2 siblings, 0 replies; 9+ messages in thread
From: Richard M. Stallman @ 2006-01-22 17:44 UTC (permalink / raw)
  Cc: emacs-devel, handa

    This message is very easy to miss.  Perhaps it should be changed to allow
    highlighting by one of the compile.el rules, for instance:

    emacs:0:warning: Pure Lisp storage overflow (approx. 1181968 bytes needed)

That is a good idea--but this should be an error, not a warning.
I will do it.

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

* Re: dump-emacs doesn't fail even if Pure Lisp storage overflows
  2006-01-22  3:19   ` Luc Teirlinck
@ 2006-01-23  1:54     ` Juri Linkov
  0 siblings, 0 replies; 9+ messages in thread
From: Juri Linkov @ 2006-01-23  1:54 UTC (permalink / raw)
  Cc: emacs-devel, handa

>    But when you then start Emacs you get the following difficult to miss
>    warning on your startup screen:
>
>       Warning Warning  Pure space overflow  Warning Warning
>
> I should have explicitly mentioned that you only see this warning if
> inhibit-splash-screen is nil (as it is by default).

I set inhibit-splash-screen to t in .emacs, so I didn't see this
warning.

> But when you then start Emacs you get the following difficult to miss
> warning on your startup screen:
>
>    Warning Warning  Pure space overflow  Warning Warning

Out of curiosity, I tried to set inhibit-splash-screen to nil, and I see
that this warning is still easy to miss even with
inhibit-splash-screen=nil: this warning is outside the main text area of
the splash screen and is not specially highlighted, e.g. in red.  Instead
of that, in red are only the line:

  GNU Emacs is one component of the GNU/Linux operating system

which attracts all attention.

> Showing it at startup should be sufficient for people to notice.
> They noticed it this time: the bug got reported on emacs-pretest-bug.

Showing this warning at startup is not sufficient for people who disable
the splash screen, so perhaps it should be displayed with `display-warning'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

* Re: dump-emacs doesn't fail even if Pure Lisp storage overflows
  2006-01-20 17:51 ` Stefan Monnier
@ 2006-01-24 11:25   ` Kenichi Handa
  0 siblings, 0 replies; 9+ messages in thread
From: Kenichi Handa @ 2006-01-24 11:25 UTC (permalink / raw)
  Cc: emacs-devel

In article <m164oevlj2.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> But, the problem is that building of Emacs proceeds even if
>> this message is shown:

>> Pure Lisp storage overflow (approx. 1173352 bytes needed)

>> And, the resulting emacs behaves very strangely.

> IIRC what happens is that it doesn't do GC, other than that it should
> behave normally.  It is useful for bootstrapping to be able to get an Emacs
> that works well enough to byte-compile some files (which will then use less
> Pure storage next time we dump them).

It seems that is true on Debian (or any other GNU/Linux
system).  But, at least on Solaris 2.8, when I change the
puresize smaller, the building fails while making "leim"
subdir.

make[1]: Entering directory `/project/mule/emacs-head/leim'
[...]
EMACSLOADPATH=/project/mule/emacs-head/leim/../lisp ../src/emacs -batch --no-init-file --no-site-file --multibyte -l /project/mule/emacs-head/leim/../lisp/international/titdic-cnv \
  -f batch-miscdic-convert -dir quail /project/mule/emacs-head/leim/MISC-DIC; \
  echo "changed" > changed.misc
Converting ziranma.cin to ZIRANMA.el...
Loading vc-cvs...
Wrong type argument: number-or-marker-p, nil

As Emacs itself was already dumped, I ran it and evalled
(miscdic-convert "MISC-DIC/ziranma.cin" "quail"), but it
sometimes fails, sometimes succeeds.  Very strange.  :-(

---
Kenichi Handa
handa@m17n.org

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

end of thread, other threads:[~2006-01-24 11:25 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-01-20  7:41 dump-emacs doesn't fail even if Pure Lisp storage overflows Kenichi Handa
2006-01-20 17:51 ` Stefan Monnier
2006-01-24 11:25   ` Kenichi Handa
2006-01-20 22:58 ` Richard M. Stallman
2006-01-22  0:48 ` Juri Linkov
2006-01-22  2:15   ` Luc Teirlinck
2006-01-22  3:19   ` Luc Teirlinck
2006-01-23  1:54     ` Juri Linkov
2006-01-22 17:44   ` Richard M. 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.