dump-emacs doesn't fail even if Pure Lisp storage overflows

dump-emacs doesn't fail even if Pure Lisp storage overflows

[Kenichi Handa]

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

Re: dump-emacs doesn't fail even if Pure Lisp storage overflows

[Stefan Monnier]

> 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

Re: dump-emacs doesn't fail even if Pure Lisp storage overflows

[Richard M. Stallman]

    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.

Re: dump-emacs doesn't fail even if Pure Lisp storage overflows

[Juri Linkov]

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

Re: dump-emacs doesn't fail even if Pure Lisp storage overflows

[Luc Teirlinck]

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.

Re: dump-emacs doesn't fail even if Pure Lisp storage overflows

[Luc Teirlinck]

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

Re: dump-emacs doesn't fail even if Pure Lisp storage overflows

[Richard M. Stallman]

    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.

Re: dump-emacs doesn't fail even if Pure Lisp storage overflows

[Juri Linkov]

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

Re: dump-emacs doesn't fail even if Pure Lisp storage overflows

[Kenichi Handa]

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