Re: Crash building unicode2, NSTATICS too low, pure space overflow.

Re: Crash building unicode2, NSTATICS too low, pure space overflow.

[Kenichi Handa]

In article <44D19F77.4050904@swipnet.se>, Jan Djärv <jan.h.d@swipnet.se> writes:

> Am I the only one that sees this:
> `/bin/pwd`/temacs --batch --load loadup bootstrap
> make[2]: *** [bootstrap-emacs] Avbruten (SIGABRT)
> make[2]: Leaving directory `/home/jhd/src/emacs-unicode2/src'
> make[1]: *** [bootstrap-build] Fel 2
> make[1]: Leaving directory `/home/jhd/src/emacs-unicode2'
> make: *** [bootstrap] Fel 2

> It aborts here (alloc.c):

> 4844    staticpro (varaddress)
> 4845         Lisp_Object *varaddress;
> 4846    {
> 4847      staticvec[staticidx++] = varaddress;
> 4848      if (staticidx >= NSTATICS)
> 4849        abort ();
> 4850    }

I recently got the same bug report from Duncan
<duncanmak@gmail.com>.  As I usually build Emacs without
gtk, I didn't notice it.  Without gtk and with
enable-font-backend, staticidx reaches 1279!  In HEAD, it
reaches 1193.

> If I increase NSTATICS to 1281 it does not abort.  This is with GTK.  When 
> compiling with GTK an extra gtk-version-string is staticpro:ed, so compiling 
> without GTK does not abort.  I also get (GTK or non-GTK version):

> emacs:0:Pure Lisp storage overflow (approx. 1211344 bytes needed)

I don't see that in non-GKT version, though.  The last step
of dumping shows this message.

Dumping under names emacs and emacs-23.0.0.6
1209872 pure bytes used

> Is it OK to just increase NSTATICS a bit?  Shouldn't staticvec be dynamically 
> allocated BTW?

It was increased from 1026 to 1280 about 4 years ago.
Perhaps there was a good reason for not chaning it to be
allocated dynamically ... I'm not sure.

1026 is 0x402, 1280 is 0x500.  What is the good value for
NSTATICS this time; 0x600 or 0x602?

---
Kenichi Handa
handa@m17n.org

Re: Crash building unicode2, NSTATICS too low, pure space overflow.

[Jan Djärv]

Kenichi Handa skrev:
> In article <44D19F77.4050904@swipnet.se>, Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> emacs:0:Pure Lisp storage overflow (approx. 1211344 bytes needed)
> 
> I don't see that in non-GKT version, though.  The last step
> of dumping shows this message.
> 
> Dumping under names emacs and emacs-23.0.0.6
> 1209872 pure bytes used
> 

I see it in a clean checkout.  Have the optimizations in HEAD been merged in?

	Jan D.

Re: Crash building unicode2, NSTATICS too low, pure space overflow.

[Richard Stallman]

    1026 is 0x402, 1280 is 0x500.  What is the good value for
    NSTATICS this time; 0x600 or 0x602?

Try 0x7f0.  That should fit nicely in a block that malloc can get
with no wasted space.

Re: Crash building unicode2, NSTATICS too low, pure space overflow.

[Kenichi Handa]

In article <E1G8ifC-0003P8-LR@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:

>     1026 is 0x402, 1280 is 0x500.  What is the good value for
>     NSTATICS this time; 0x600 or 0x602?

> Try 0x7f0.  That should fit nicely in a block that malloc can get
> with no wasted space.

Thank you.  I've just installed that change.

By the way, is it true that allocating "Lisp_Object
*staticvec" dynamically (i.e. by malloc and realloc) doesn't
work?

---
Kenichi Handa
handa@m17n.org

Re: Crash building unicode2, NSTATICS too low, pure space overflow.

[Richard Stallman]

    By the way, is it true that allocating "Lisp_Object
    *staticvec" dynamically (i.e. by malloc and realloc) doesn't
    work?

I think nobody tried it.  There is no reason to go to the trouble.

Re: Crash building unicode2, NSTATICS too low, pure space overflow.

[Jan Djärv]

Kenichi Handa skrev:
> In article <E1G8ifC-0003P8-LR@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:
> 
>>     1026 is 0x402, 1280 is 0x500.  What is the good value for
>>     NSTATICS this time; 0x600 or 0x602?
> 
>> Try 0x7f0.  That should fit nicely in a block that malloc can get
>> with no wasted space.
> 
> Thank you.  I've just installed that change.

I don't see this change in HEAD or emacs-unicode2.  Where did you check it in?

	Jan D.

Re: Crash building unicode2, NSTATICS too low, pure space overflow.

[Kenichi Handa]

In article <44D6DCA0.7010308@swipnet.se>, Jan Djärv <jan.h.d@swipnet.se> writes:

> Kenichi Handa skrev:
>> In article <E1G8ifC-0003P8-LR@fencepost.gnu.org>, Richard
>> Stallman <rms@gnu.org> writes:
>> 
>>> 1026 is 0x402, 1280 is 0x500.  What is the good value
>>> for NSTATICS this time; 0x600 or 0x602?
>> 
>>> Try 0x7f0.  That should fit nicely in a block that
>>> malloc can get with no wasted space.
>> 
>> Thank you.  I've just installed that change.

> I don't see this change in HEAD or emacs-unicode2.  Where
> did you check it in?

Sorry, I've committed the change surely this time (not to
0x7f0 but to 0x600 according to this RMS's mail).

Richard Stallman <rms@gnu.org> writes:

> I had forgotten that.  Since it is statically allocated,
> might as well just make it 0x600.  It will last us another
> few years.

---
Kenichi Handa
handa@m17n.org

Re: Crash building unicode2, NSTATICS too low, pure space overflow.

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

>     1026 is 0x402, 1280 is 0x500.  What is the good value for
>     NSTATICS this time; 0x600 or 0x602?
>
> Try 0x7f0.  That should fit nicely in a block that malloc can get
> with no wasted space.

Since staticvec is statically allocated there is no need to care for
malloc overhead.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Crash building unicode2, NSTATICS too low, pure space overflow.

[Duncan Mak]

[-- Attachment #1.1: Type: text/plain, Size: 472 bytes --]

With the following two patches, I was able to build emacs:

in puresize.h

-#define BASE_PURESIZE (1102000 + SYSTEM_PURESIZE_EXTRA +
SITELOAD_PURESIZE_EXTRA)
+#define BASE_PURESIZE (1235000 + SYSTEM_PURESIZE_EXTRA +
SITELOAD_PURESIZE_EXTRA)

in alloc.c

-#define NSTATICS 1280
+#define NSTATICS 2032

However, I can't type anything into the buffer in the resulting emacs.

I configured it with:

./configure --with-x-toolkit=gtk --enable-font-backend  --with-xft

Duncan.

[-- Attachment #1.2: Type: text/html, Size: 652 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Crash building unicode2, NSTATICS too low, pure space overflow.

[David Kastrup]

"Duncan Mak" <duncanmak@gmail.com> writes:

> With the following two patches, I was able to build emacs:
>
> in puresize.h
>
> -#define BASE_PURESIZE (1102000 + SYSTEM_PURESIZE_EXTRA +
> SITELOAD_PURESIZE_EXTRA)
> +#define BASE_PURESIZE (1235000 + SYSTEM_PURESIZE_EXTRA +
> SITELOAD_PURESIZE_EXTRA)
>
> in alloc.c
>
> -#define NSTATICS 1280
> +#define NSTATICS 2032
>
> However, I can't type anything into the buffer in the resulting emacs.
>
> I configured it with:
>
> ./configure --with-x-toolkit=gtk --enable-font-backend  --with-xft

Did you recompile all the Lisp files?

make bootstrap?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Crash building unicode2, NSTATICS too low, pure space overflow.

[Duncan Mak]

[-- Attachment #1.1: Type: text/plain, Size: 134 bytes --]

On 8/4/06, David Kastrup <dak@gnu.org> wrote:

> Did you recompile all the Lisp files?
>
> make bootstrap?


Yes, of course.

Duncan.

[-- Attachment #1.2: Type: text/html, Size: 422 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Crash building unicode2, NSTATICS too low, pure space overflow.

[Richard Stallman]

    > Try 0x7f0.  That should fit nicely in a block that malloc can get
    > with no wasted space.

    Since staticvec is statically allocated there is no need to care for
    malloc overhead.

I had forgotten that.  Since it is statically allocated, might as well
just make it 0x600.  It will last us another few years.