GNU bug report logs -
#2403
23.0.90; emacs bootstrap under AIX hangs at lisp/international/characters.el
Previous Next
Reported by: Ulrich Mueller <ulm <at> gentoo.org>
Date: Fri, 20 Feb 2009 05:05:05 UTC
Severity: normal
Tags: patch
Done: Ulrich Mueller <ulm <at> gentoo.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 2403 in the body.
You can then email your comments to 2403 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#2403; Package
emacs.
(Fri, 20 Feb 2009 05:05:05 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Harald Maier <harald <at> maierh.de>:
New bug report received and forwarded. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>.
(Fri, 20 Feb 2009 05:05:05 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):
I am trying to build emacs-23.0.90 under AIX but it hangs at loading the
characters.el file:
----------------------------------------------------------------------
...
Loading /usr/maierha/build/cvs/emacs/lisp/international/mule-cmds.el (source)...
Loading /usr/maierha/build/cvs/emacs/lisp/case-table.el (source)...
Loading /usr/maierha/build/cvs/emacs/lisp/international/characters.el (source)...
----------------------------------------------------------------------
This happens on AIX 5.2 and AIX 5.3 and I am using the latest CVS
version. It looks that temacs is in an enless loop. Any idea what the
problem might be?
Harald
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#2403; Package
emacs.
(Thu, 26 Feb 2009 18:35:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Harald Maier <harald <at> maierh.de>:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>.
(Thu, 26 Feb 2009 18:35:02 GMT)
Full text and
rfc822 format available.
Message #10 received at 2403 <at> emacsbugs.donarmstrong.com (full text, mbox):
Harald Maier <harald <at> maierh.de> writes:
> I am trying to build emacs-23.0.90 under AIX but it hangs at loading the
> characters.el file:
>
> ----------------------------------------------------------------------
> ...
> Loading /usr/maierha/build/cvs/emacs/lisp/international/mule-cmds.el (source)...
> Loading /usr/maierha/build/cvs/emacs/lisp/case-table.el (source)...
> Loading /usr/maierha/build/cvs/emacs/lisp/international/characters.el (source)...
> ----------------------------------------------------------------------
>
> This happens on AIX 5.2 and AIX 5.3 and I am using the latest CVS
> version. It looks that temacs is in an enless loop. Any idea what the
> problem might be?
I digged a little bit deeper to this problem. temacs is in a endless
loop in the following for loop in the alloca.c file:
--- alloca.c:5101 ---
#if (GC_MARK_STACK == GC_MAKE_GCPROS_NOOPS \
|| GC_MARK_STACK == GC_MARK_STACK_CHECK_GCPROS)
mark_stack ();
#else
{
register struct gcpro *tail;
=> for (tail = gcprolist; tail; tail = tail->next)
for (i = 0; i < tail->nvars; i++)
mark_object (tail->var[i]);
}
#endif
---------------------
If I examine the values in gdb then I see that the second element of
gcprolist points to itself in the next element. That's why emacs loops.
---------------------
(gdb) p gcprolist
$6 = (struct gcpro *) 0x2ff20b68
(gdb) p *gcprolist
$7 = {
next = 0x2ff20bcc,
var = 0x2ff20b74,
nvars = 3
}
(gdb) p *0x2ff20bcc
$8 = 804391884
(gdb) p * (struct gcpro *) 0x2ff20bcc
$9 = {
next = 0x2ff20bcc,
var = 0x2ff20bc8,
nvars = 1
}
---------------------
Any idea how to fix that? As I mentioned before on my site this happens
with AIX 5.2 and 5.3 and it doesn't matter whether it's compiled with
gcc or the IBM compiler. Emacs is configured only with X11 (no gtk an
image support).
Harald
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#2403; Package
emacs.
(Thu, 26 Feb 2009 18:35:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Harald Maier <harald <at> maierh.de>:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>.
(Thu, 26 Feb 2009 18:35:04 GMT)
Full text and
rfc822 format available.
Message #15 received at 2403 <at> emacsbugs.donarmstrong.com (full text, mbox):
Harald Maier <harald <at> maierh.de> writes:
> Harald Maier <harald <at> maierh.de> writes:
>
>> I am trying to build emacs-23.0.90 under AIX but it hangs at loading the
>> characters.el file:
>>
>> ----------------------------------------------------------------------
>> ...
>> Loading /usr/maierha/build/cvs/emacs/lisp/international/mule-cmds.el (source)...
>> Loading /usr/maierha/build/cvs/emacs/lisp/case-table.el (source)...
>> Loading /usr/maierha/build/cvs/emacs/lisp/international/characters.el (source)...
>> ----------------------------------------------------------------------
>>
>> This happens on AIX 5.2 and AIX 5.3 and I am using the latest CVS
>> version. It looks that temacs is in an enless loop. Any idea what the
>> problem might be?
>
> I digged a little bit deeper to this problem. temacs is in a endless
> loop in the following for loop in the alloca.c file:
>
> --- alloca.c:5101 ---
> #if (GC_MARK_STACK == GC_MAKE_GCPROS_NOOPS \
Uups, I meant "alloc.c".
Harald
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#2403; Package
emacs.
(Thu, 26 Feb 2009 19:45:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Eli Zaretskii <eliz <at> gnu.org>:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>.
(Thu, 26 Feb 2009 19:45:03 GMT)
Full text and
rfc822 format available.
Message #20 received at 2403 <at> emacsbugs.donarmstrong.com (full text, mbox):
> From: Harald Maier <harald <at> maierh.de>
> Date: Thu, 26 Feb 2009 19:26:00 +0100
> Cc:
>
> Harald Maier <harald <at> maierh.de> writes:
>
> > I am trying to build emacs-23.0.90 under AIX but it hangs at loading the
> > characters.el file:
> >
> > ----------------------------------------------------------------------
> > ...
> > Loading /usr/maierha/build/cvs/emacs/lisp/international/mule-cmds.el (source)...
> > Loading /usr/maierha/build/cvs/emacs/lisp/case-table.el (source)...
> > Loading /usr/maierha/build/cvs/emacs/lisp/international/characters.el (source)...
> > ----------------------------------------------------------------------
> >
> > This happens on AIX 5.2 and AIX 5.3 and I am using the latest CVS
> > version. It looks that temacs is in an enless loop. Any idea what the
> > problem might be?
>
> I digged a little bit deeper to this problem. temacs is in a endless
> loop in the following for loop in the alloca.c file:
>
> --- alloca.c:5101 ---
> #if (GC_MARK_STACK == GC_MAKE_GCPROS_NOOPS \
> || GC_MARK_STACK == GC_MARK_STACK_CHECK_GCPROS)
> mark_stack ();
> #else
> {
> register struct gcpro *tail;
> => for (tail = gcprolist; tail; tail = tail->next)
> for (i = 0; i < tail->nvars; i++)
> mark_object (tail->var[i]);
> }
> #endif
> ---------------------
> If I examine the values in gdb then I see that the second element of
> gcprolist points to itself in the next element. That's why emacs loops.
Could it be that Emacs doesn't have enough stack space? (I have no
idea whether stack on AIX is statically allocated and what is its
default size.)
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#2403; Package
emacs.
(Thu, 26 Feb 2009 20:10:05 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Harald Maier <harald <at> maierh.de>:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>.
(Thu, 26 Feb 2009 20:10:05 GMT)
Full text and
rfc822 format available.
Message #25 received at 2403 <at> emacsbugs.donarmstrong.com (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Harald Maier <harald <at> maierh.de>
>> Date: Thu, 26 Feb 2009 19:26:00 +0100
>> Cc:
>>
>> Harald Maier <harald <at> maierh.de> writes:
>>
>> > I am trying to build emacs-23.0.90 under AIX but it hangs at loading the
>> > characters.el file:
>> >
>> > ----------------------------------------------------------------------
>> > ...
>> > Loading /usr/maierha/build/cvs/emacs/lisp/international/mule-cmds.el (source)...
>> > Loading /usr/maierha/build/cvs/emacs/lisp/case-table.el (source)...
>> > Loading /usr/maierha/build/cvs/emacs/lisp/international/characters.el (source)...
>> > ----------------------------------------------------------------------
>> >
>> > This happens on AIX 5.2 and AIX 5.3 and I am using the latest CVS
>> > version. It looks that temacs is in an enless loop. Any idea what the
>> > problem might be?
>>
>> I digged a little bit deeper to this problem. temacs is in a endless
>> loop in the following for loop in the alloca.c file:
>>
>> --- alloca.c:5101 ---
>> #if (GC_MARK_STACK == GC_MAKE_GCPROS_NOOPS \
>> || GC_MARK_STACK == GC_MARK_STACK_CHECK_GCPROS)
>> mark_stack ();
>> #else
>> {
>> register struct gcpro *tail;
>> => for (tail = gcprolist; tail; tail = tail->next)
>> for (i = 0; i < tail->nvars; i++)
>> mark_object (tail->var[i]);
>> }
>> #endif
>> ---------------------
>> If I examine the values in gdb then I see that the second element of
>> gcprolist points to itself in the next element. That's why emacs loops.
>
> Could it be that Emacs doesn't have enough stack space? (I have no
> idea whether stack on AIX is statically allocated and what is its
> default size.)
Definitely not. Both machines has lots of resources and also Emacs 22
compiles and works very well. But I can verify that if you can give me
some hints how to do this.
Harald
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#2403; Package
emacs.
(Thu, 26 Feb 2009 20:55:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stefan Monnier <monnier <at> iro.umontreal.ca>:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>.
(Thu, 26 Feb 2009 20:55:04 GMT)
Full text and
rfc822 format available.
Message #30 received at 2403 <at> emacsbugs.donarmstrong.com (full text, mbox):
> I digged a little bit deeper to this problem. temacs is in an endless
> loop in the following for loop in the alloca.c file:
> --- alloca.c:5101 ---
> #if (GC_MARK_STACK == GC_MAKE_GCPROS_NOOPS \
> || GC_MARK_STACK == GC_MARK_STACK_CHECK_GCPROS)
> mark_stack ();
> #else
> {
> register struct gcpro *tail;
> => for (tail = gcprolist; tail; tail = tail->next)
> for (i = 0; i < tail->nvars; i++)
> mark_object (tail->var[i]);
> }
> #endif
> ---------------------
> If I examine the values in gdb then I see that the second element of
> gcprolist points to itself in the next element. That's why emacs loops.
> Any idea how to fix that?
No idea. This should never happen, obviously. The gcprolist (and its
elements) should only ever be touched by the macros GCPRO<n> and
UNGCPRO, so the only thing that comes to mind is that someone does
GCPRO1 twice in the same block.
You may want to add some
eassert(gcprolist != &gcpro<n>);
to the GCPRO macros which may catch the bug. Alternatively, if you look
at the backtrace, the problematic uses of GCPRO<n> should be nearby.
Of course, maybe the problem really is one of the stack being clobbered.
Stefan
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#2403; Package
emacs.
(Fri, 27 Feb 2009 10:30:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Eli Zaretskii <eliz <at> gnu.org>:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>.
(Fri, 27 Feb 2009 10:30:04 GMT)
Full text and
rfc822 format available.
Message #35 received at 2403 <at> emacsbugs.donarmstrong.com (full text, mbox):
> From: Harald Maier <harald <at> maierh.de>
> Cc: 2403 <at> emacsbugs.donarmstrong.com
> Date: Thu, 26 Feb 2009 21:02:57 +0100
>
> > Could it be that Emacs doesn't have enough stack space? (I have no
> > idea whether stack on AIX is statically allocated and what is its
> > default size.)
>
> Definitely not. Both machines has lots of resources and also Emacs 22
> compiles and works very well.
On many systems, Emacs 23 needs much more stack space than Emacs 22,
especially when characters.el is loaded during dumping.
> But I can verify that if you can give me some hints how to do this.
Sorry, I don't use AIX and am not familiar with that system enough to
give you any useful advice. For starters, please find out how much
stack temacs has when it performs this command from src/Makefile:
LC_ALL=C $(RUN_TEMACS) -batch -l loadup dump
(Again, I cannot tell you how to do that on AIX, unfortunately.)
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#2403; Package
emacs.
(Fri, 06 Mar 2009 21:25:06 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Criveti Mihai <crivetimihai <at> gmail.com>:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>.
(Fri, 06 Mar 2009 21:25:06 GMT)
Full text and
rfc822 format available.
Message #40 received at 2403 <at> emacsbugs.donarmstrong.com (full text, mbox):
/etc/security/limits sets:
default:
stack = 131072
May want to try settings
stack = 524288
stack_hard = 524288
or even higher for building Emacs.
Also check ulimit -s / ulimit -a values.
On Fri, Feb 27, 2009 at 12:27 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Harald Maier <harald <at> maierh.de>
>> Cc: 2403 <at> emacsbugs.donarmstrong.com
>> Date: Thu, 26 Feb 2009 21:02:57 +0100
>>
>> > Could it be that Emacs doesn't have enough stack space? (I have no
>> > idea whether stack on AIX is statically allocated and what is its
>> > default size.)
>>
>> Definitely not. Both machines has lots of resources and also Emacs 22
>> compiles and works very well.
>
> On many systems, Emacs 23 needs much more stack space than Emacs 22,
> especially when characters.el is loaded during dumping.
>
>> But I can verify that if you can give me some hints how to do this.
>
> Sorry, I don't use AIX and am not familiar with that system enough to
> give you any useful advice. For starters, please find out how much
> stack temacs has when it performs this command from src/Makefile:
>
> LC_ALL=C $(RUN_TEMACS) -batch -l loadup dump
>
> (Again, I cannot tell you how to do that on AIX, unfortunately.)
>
>
>
>
>
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#2403; Package
emacs.
(Fri, 06 Mar 2009 23:10:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Criveti Mihai <crivetimihai <at> gmail.com>:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>.
(Fri, 06 Mar 2009 23:10:04 GMT)
Full text and
rfc822 format available.
Message #45 received at 2403 <at> emacsbugs.donarmstrong.com (full text, mbox):
Emacs is confiugred --with-x=no, ulimits are all unlimited.
cmihai <at> phobos:/home/cmihai/newbuild/emacs/src$ LC_ALL=C ./temacs
--batch --load loadup bootstrap dump
Loading loadup.el (source)...
Using load-path (/home/cmihai/newbuild/emacs/lisp
/home/cmihai/newbuild/emacs/lisp/emacs-lisp
/home/cmihai/newbuild/emacs/lisp/language
/home/cmihai/newbuild/emacs/lisp/international
/home/cmihai/newbuild/emacs/lisp/textmodes)
Loading emacs-lisp/byte-run (source)...
Loading emacs-lisp/backquote (source)...
Loading subr (source)...
Loading version.el (source)...
Loading widget (source)...
Loading custom (source)...
Loading emacs-lisp/map-ynp (source)...
Loading cus-start (source)...
Loading international/mule (source)...
Loading international/mule-conf.el (source)...
Loading env (source)...
Loading format (source)...
Loading bindings (source)...
Loading /home/cmihai/newbuild/emacs/lisp/files.el (source)...
Loading /home/cmihai/newbuild/emacs/lisp/cus-face.el (source)...
Loading /home/cmihai/newbuild/emacs/lisp/faces.el (source)...
Loading /home/cmihai/newbuild/emacs/lisp/minibuffer.el (source)...
Loading /home/cmihai/newbuild/emacs/lisp/button.el (source)...
Loading /home/cmihai/newbuild/emacs/lisp/startup.el (source)...
Lists of integers (garbage collection statistics) are normal output
while building Emacs; they do not indicate a problem.
((120124 . 7654) (6419 . 3) (556 . 148) 484706 22404 (37 . 1) (22 . 5)
(9678 . 6198))
Loading /home/cmihai/newbuild/emacs/lisp/ldefs-boot.el (source)...
((142077 . 5261) (9199 . 0) (564 . 140) 1422768 22404 (107 . 33) (22 .
5) (17962 . 1946))
Loading /home/cmihai/newbuild/emacs/lisp/abbrev.el (source)...
Loading /home/cmihai/newbuild/emacs/lisp/simple.el (source)...
Loading /home/cmihai/newbuild/emacs/lisp/help.el (source)...
Loading /home/cmihai/newbuild/emacs/lisp/jka-cmpr-hook.el (source)...
Loading /home/cmihai/newbuild/emacs/lisp/epa-hook.el (source)...
Loading /home/cmihai/newbuild/emacs/lisp/international/mule-cmds.el (source)...
Loading /home/cmihai/newbuild/emacs/lisp/case-table.el (source)...
Loading /home/cmihai/newbuild/emacs/lisp/international/characters.el (source)...
Freezes here.
truss ./temacs --batch --load loadup bootstrap
statx("/home/cmihai/newbuild/emacs/lisp/case-table.el", 0x2FF219D0,
128, 010) = 0
open("/home/cmihai/newbuild/emacs/lisp/case-table.el", O_RDONLY|O_LARGEFILE) = 4
kread(4, " ; ; ; c a s e - t a b".., 511) = 511
klseek(4, 0, 0, 0x00000000) = 0
close(4) = 0
statx("/home/cmihai/newbuild/emacs/lisp/case-table.el", 0x2FF21490,
128, 010) = 0
open("/home/cmihai/newbuild/emacs/lisp/case-table.el", O_RDONLY|O_LARGEFILE) = 4
close(4) = 0
Loading /home/cmihai/newbuild/emacs/lisp/case-table.el
(source)...kwrite(2, " L o a d i n g / h o m".., 66) = 66
kwrite(2, "\n", 1) = 1
kfcntl(2, F_GETFL, 0x2FF22FFC) = 67110914
statx("/home/cmihai/newbuild/emacs/lisp/case-table.el", 0x2FF0C888,
128, 010) = 0
open("/home/cmihai/newbuild/emacs/lisp/case-table.el", O_RDONLY|O_LARGEFILE) = 4
kread(4, " ; ; ; c a s e - t a b".., 6452) = 6452
close(4) = 0
readlink("/home", "", 100) Err#22 EINVAL
readlink("/home/cmihai", "", 100) Err#22 EINVAL
readlink("/home/cmihai/newbuild", "", 100) Err#22 EINVAL
readlink("/home/cmihai/newbuild/emacs", "", 100) Err#22 EINVAL
readlink("/home/cmihai/newbuild/emacs/lisp", "", 100) Err#22 EINVAL
readlink("/home/cmihai/newbuild/emacs/lisp/case-table.el", "", 100)
Err#22 EINVAL
statx("/home/cmihai/newbuild/emacs/lisp/international/characters.elc",
0x2FF219D0, 128, 010) Err#2 ENOENT
statx("/home/cmihai/newbuild/emacs/lisp/international/characters.elc.gz",
0x2FF219D0, 128, 010) Err#2 ENOENT
statx("/home/cmihai/newbuild/emacs/lisp/international/characters.el",
0x2FF219D0, 128, 010) = 0
open("/home/cmihai/newbuild/emacs/lisp/international/characters.el",
O_RDONLY|O_LARGEFILE) = 4
kread(4, " ; ; ; c h a r a c t e".., 511) = 511
klseek(4, 0, 0, 0x00000000) = 0
close(4) = 0
statx("/home/cmihai/newbuild/emacs/lisp/international/characters.el",
0x2FF21490, 128, 010) = 0
open("/home/cmihai/newbuild/emacs/lisp/international/characters.el",
O_RDONLY|O_LARGEFILE) = 4
close(4) = 0
Loading /home/cmihai/newbuild/emacs/lisp/international/characters.el
(source)...kwrite(2, " L o a d i n g / h o m".., 80) = 80
kwrite(2, "\n", 1) = 1
kfcntl(2, F_GETFL, 0x2FF22FFC) = 67110914
statx("/home/cmihai/newbuild/emacs/lisp/international/characters.el",
0x2FF0C888, 128, 010) = 0
open("/home/cmihai/newbuild/emacs/lisp/international/characters.el",
O_RDONLY|O_LARGEFILE) = 4
kread(4, " ; ; ; c h a r a c t e".., 38015) = 38015
close(4) = 0
readlink("/home", "", 100) Err#22 EINVAL
readlink("/home/cmihai", "", 100) Err#22 EINVAL
readlink("/home/cmihai/newbuild", "", 100) Err#22 EINVAL
readlink("/home/cmihai/newbuild/emacs", "", 100) Err#22 EINVAL
readlink("/home/cmihai/newbuild/emacs/lisp", "", 100) Err#22 EINVAL
readlink("/home/cmihai/newbuild/emacs/lisp/international", "", 100)
Err#22 EINVAL
readlink("/home/cmihai/newbuild/emacs/lisp/international/characters.el",
"", 100) Err#22 EINVAL
statx("/home/cmihai/newbuild/emacs/etc/charsets/GB2312.map",
0x2FF20BF0, 128, 010) = 0
open("/home/cmihai/newbuild/emacs/etc/charsets/GB2312.map",
O_RDONLY|O_LARGEFILE) = 4
kfcntl(4, F_GETFL, 0x2FF22FFC) = 67108864
kioctl(4, 22528, 0x00000000, 0x00000000) Err#25 ENOTTY
kioctl(4, 22528, 0x00000000, 0x00000000) Err#25 ENOTTY
kread(4, " # G e n e r a t e d ".., 4096) = 4096
kread(4, " x 5 F C 5\n 0 x 3 1 5 9".., 4096) = 4096
kread(4, " 6 D E C\n 0 x 3 4 6 4 ".., 4096) = 4096
kread(4, " 7 6 E 0 x 5 9 4 9\n 0".., 4096) = 4096
kread(4, " F 6\n 0 x 3 A 7 9 0 x".., 4096) = 4096
kread(4, " 5 0 x 8 3 0 E\n 0 x 3".., 4096) = 4096
kread(4, "\n 0 x 4 1 3 0 0 x 6 D".., 4096) = 4096
kread(4, " 0 x 6 6 A E\n 0 x 4 4 3".., 4096) = 4096
kread(4, " x 4 7 4 5 0 x 6 8 6 5".., 4096) = 4096
kread(4, " 4 A 5 0 0 x 5 E 0 2\n".., 4096) = 4096
kread(4, " 3 1 6\n 0 x 4 D 5 B 0".., 4096) = 4096
kread(4, " 6 5 0 x 7 E E 3\n 0 x".., 4096) = 4096
kread(4, " 0 0 x 7 F B D\n 0 x 5".., 4096) = 4096
kread(4, " 0 x 8 6 C 0\n 0 x 5 6".., 4096) = 4096
kread(4, " 0 x 5 A 2 F 0 x 8 B C".., 4096) = 4096
kread(4, " x 5 D 4 6 0 x 8 4 1 C".., 4096) = 4096
kread(4, " 5 6 5 8\n 0 x 6 0 5 A ".., 4096) = 4096
kread(4, " C D 7\n 0 x 6 3 7 5 0".., 4096) = 4096
kread(4, " 2 B 0 x 7 E D 4\n 0 x".., 4096) = 4096
kread(4, " C\n 0 x 6 A 5 3 0 x 6".., 4096) = 4096
kread(4, "\n 0 x 6 D 7 0 - 0 x 6 D".., 4096) = 4096
kread(4, " 0 x 8 9 3 6\n 0 x 7 1 5".., 4096) = 4096
kread(4, " x 7 4 7 4 0 x 8 D 9 1".., 4096) = 3443
kread(4, " x 7 4 7 4 0 x 8 D 9 1".., 4096) = 0
close(4) = 0
close(4) Err#9 EBADF
sbrk(0x00000000) = 0x20898000
sbrk(0x00069000) = 0x20898000
It just freezes here.
On Fri, Mar 6, 2009 at 11:19 PM, Criveti Mihai <crivetimihai <at> gmail.com> wrote:
> /etc/security/limits sets:
> default:
> stack = 131072
>
> May want to try settings
> stack = 524288
> stack_hard = 524288
> or even higher for building Emacs.
>
> Also check ulimit -s / ulimit -a values.
>
> On Fri, Feb 27, 2009 at 12:27 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>> From: Harald Maier <harald <at> maierh.de>
>>> Cc: 2403 <at> emacsbugs.donarmstrong.com
>>> Date: Thu, 26 Feb 2009 21:02:57 +0100
>>>
>>> > Could it be that Emacs doesn't have enough stack space? (I have no
>>> > idea whether stack on AIX is statically allocated and what is its
>>> > default size.)
>>>
>>> Definitely not. Both machines has lots of resources and also Emacs 22
>>> compiles and works very well.
>>
>> On many systems, Emacs 23 needs much more stack space than Emacs 22,
>> especially when characters.el is loaded during dumping.
>>
>>> But I can verify that if you can give me some hints how to do this.
>>
>> Sorry, I don't use AIX and am not familiar with that system enough to
>> give you any useful advice. For starters, please find out how much
>> stack temacs has when it performs this command from src/Makefile:
>>
>> LC_ALL=C $(RUN_TEMACS) -batch -l loadup dump
>>
>> (Again, I cannot tell you how to do that on AIX, unfortunately.)
>>
>>
>>
>>
>>
>
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#2403; Package
emacs.
(Sat, 07 Mar 2009 01:40:04 GMT)
Full text and
rfc822 format available.
Message #48 received at 2403 <at> emacsbugs.donarmstrong.com (full text, mbox):
Criveti Mihai <crivetimihai <at> gmail.com> writes:
> Emacs is confiugred --with-x=no, ulimits are all unlimited.
>
> cmihai <at> phobos:/home/cmihai/newbuild/emacs/src$ LC_ALL=C ./temacs
> --batch --load loadup bootstrap dump
> Loading loadup.el (source)...
> Using load-path (/home/cmihai/newbuild/emacs/lisp
> /home/cmihai/newbuild/emacs/lisp/emacs-lisp
> /home/cmihai/newbuild/emacs/lisp/language
> /home/cmihai/newbuild/emacs/lisp/international
> /home/cmihai/newbuild/emacs/lisp/textmodes)
> Loading emacs-lisp/byte-run (source)...
> Loading emacs-lisp/backquote (source)...
> Loading subr (source)...
> Loading version.el (source)...
> Loading widget (source)...
> Loading custom (source)...
> Loading emacs-lisp/map-ynp (source)...
> Loading cus-start (source)...
> Loading international/mule (source)...
> Loading international/mule-conf.el (source)...
> Loading env (source)...
> Loading format (source)...
> Loading bindings (source)...
> Loading /home/cmihai/newbuild/emacs/lisp/files.el (source)...
> Loading /home/cmihai/newbuild/emacs/lisp/cus-face.el (source)...
> Loading /home/cmihai/newbuild/emacs/lisp/faces.el (source)...
> Loading /home/cmihai/newbuild/emacs/lisp/minibuffer.el (source)...
> Loading /home/cmihai/newbuild/emacs/lisp/button.el (source)...
> Loading /home/cmihai/newbuild/emacs/lisp/startup.el (source)...
> Lists of integers (garbage collection statistics) are normal output
> while building Emacs; they do not indicate a problem.
> ((120124 . 7654) (6419 . 3) (556 . 148) 484706 22404 (37 . 1) (22 . 5)
> (9678 . 6198))
> Loading /home/cmihai/newbuild/emacs/lisp/ldefs-boot.el (source)...
> ((142077 . 5261) (9199 . 0) (564 . 140) 1422768 22404 (107 . 33) (22 .
> 5) (17962 . 1946))
> Loading /home/cmihai/newbuild/emacs/lisp/abbrev.el (source)...
> Loading /home/cmihai/newbuild/emacs/lisp/simple.el (source)...
> Loading /home/cmihai/newbuild/emacs/lisp/help.el (source)...
> Loading /home/cmihai/newbuild/emacs/lisp/jka-cmpr-hook.el (source)...
> Loading /home/cmihai/newbuild/emacs/lisp/epa-hook.el (source)...
> Loading /home/cmihai/newbuild/emacs/lisp/international/mule-cmds.el (source)...
> Loading /home/cmihai/newbuild/emacs/lisp/case-table.el (source)...
> Loading /home/cmihai/newbuild/emacs/lisp/international/characters.el (source)...
>
>
> Freezes here.
>
> truss ./temacs --batch --load loadup bootstrap
> statx("/home/cmihai/newbuild/emacs/lisp/case-table.el", 0x2FF219D0,
> 128, 010) = 0
> open("/home/cmihai/newbuild/emacs/lisp/case-table.el", O_RDONLY|O_LARGEFILE) = 4
> kread(4, " ; ; ; c a s e - t a b".., 511) = 511
> klseek(4, 0, 0, 0x00000000) = 0
> close(4) = 0
> statx("/home/cmihai/newbuild/emacs/lisp/case-table.el", 0x2FF21490,
> 128, 010) = 0
> open("/home/cmihai/newbuild/emacs/lisp/case-table.el", O_RDONLY|O_LARGEFILE) = 4
> close(4) = 0
> Loading /home/cmihai/newbuild/emacs/lisp/case-table.el
> (source)...kwrite(2, " L o a d i n g / h o m".., 66) = 66
>
> kwrite(2, "\n", 1) = 1
> kfcntl(2, F_GETFL, 0x2FF22FFC) = 67110914
> statx("/home/cmihai/newbuild/emacs/lisp/case-table.el", 0x2FF0C888,
> 128, 010) = 0
> open("/home/cmihai/newbuild/emacs/lisp/case-table.el", O_RDONLY|O_LARGEFILE) = 4
> kread(4, " ; ; ; c a s e - t a b".., 6452) = 6452
> close(4) = 0
> readlink("/home", "", 100) Err#22 EINVAL
> readlink("/home/cmihai", "", 100) Err#22 EINVAL
> readlink("/home/cmihai/newbuild", "", 100) Err#22 EINVAL
> readlink("/home/cmihai/newbuild/emacs", "", 100) Err#22 EINVAL
> readlink("/home/cmihai/newbuild/emacs/lisp", "", 100) Err#22 EINVAL
> readlink("/home/cmihai/newbuild/emacs/lisp/case-table.el", "", 100)
> Err#22 EINVAL
> statx("/home/cmihai/newbuild/emacs/lisp/international/characters.elc",
> 0x2FF219D0, 128, 010) Err#2 ENOENT
> statx("/home/cmihai/newbuild/emacs/lisp/international/characters.elc.gz",
> 0x2FF219D0, 128, 010) Err#2 ENOENT
> statx("/home/cmihai/newbuild/emacs/lisp/international/characters.el",
> 0x2FF219D0, 128, 010) = 0
> open("/home/cmihai/newbuild/emacs/lisp/international/characters.el",
> O_RDONLY|O_LARGEFILE) = 4
> kread(4, " ; ; ; c h a r a c t e".., 511) = 511
> klseek(4, 0, 0, 0x00000000) = 0
> close(4) = 0
> statx("/home/cmihai/newbuild/emacs/lisp/international/characters.el",
> 0x2FF21490, 128, 010) = 0
> open("/home/cmihai/newbuild/emacs/lisp/international/characters.el",
> O_RDONLY|O_LARGEFILE) = 4
> close(4) = 0
> Loading /home/cmihai/newbuild/emacs/lisp/international/characters.el
> (source)...kwrite(2, " L o a d i n g / h o m".., 80) = 80
>
> kwrite(2, "\n", 1) = 1
> kfcntl(2, F_GETFL, 0x2FF22FFC) = 67110914
> statx("/home/cmihai/newbuild/emacs/lisp/international/characters.el",
> 0x2FF0C888, 128, 010) = 0
> open("/home/cmihai/newbuild/emacs/lisp/international/characters.el",
> O_RDONLY|O_LARGEFILE) = 4
> kread(4, " ; ; ; c h a r a c t e".., 38015) = 38015
> close(4) = 0
> readlink("/home", "", 100) Err#22 EINVAL
> readlink("/home/cmihai", "", 100) Err#22 EINVAL
> readlink("/home/cmihai/newbuild", "", 100) Err#22 EINVAL
> readlink("/home/cmihai/newbuild/emacs", "", 100) Err#22 EINVAL
> readlink("/home/cmihai/newbuild/emacs/lisp", "", 100) Err#22 EINVAL
> readlink("/home/cmihai/newbuild/emacs/lisp/international", "", 100)
> Err#22 EINVAL
> readlink("/home/cmihai/newbuild/emacs/lisp/international/characters.el",
> "", 100) Err#22 EINVAL
> statx("/home/cmihai/newbuild/emacs/etc/charsets/GB2312.map",
> 0x2FF20BF0, 128, 010) = 0
> open("/home/cmihai/newbuild/emacs/etc/charsets/GB2312.map",
> O_RDONLY|O_LARGEFILE) = 4
> kfcntl(4, F_GETFL, 0x2FF22FFC) = 67108864
> kioctl(4, 22528, 0x00000000, 0x00000000) Err#25 ENOTTY
> kioctl(4, 22528, 0x00000000, 0x00000000) Err#25 ENOTTY
> kread(4, " # G e n e r a t e d ".., 4096) = 4096
> kread(4, " x 5 F C 5\n 0 x 3 1 5 9".., 4096) = 4096
> kread(4, " 6 D E C\n 0 x 3 4 6 4 ".., 4096) = 4096
> kread(4, " 7 6 E 0 x 5 9 4 9\n 0".., 4096) = 4096
> kread(4, " F 6\n 0 x 3 A 7 9 0 x".., 4096) = 4096
> kread(4, " 5 0 x 8 3 0 E\n 0 x 3".., 4096) = 4096
> kread(4, "\n 0 x 4 1 3 0 0 x 6 D".., 4096) = 4096
> kread(4, " 0 x 6 6 A E\n 0 x 4 4 3".., 4096) = 4096
> kread(4, " x 4 7 4 5 0 x 6 8 6 5".., 4096) = 4096
> kread(4, " 4 A 5 0 0 x 5 E 0 2\n".., 4096) = 4096
> kread(4, " 3 1 6\n 0 x 4 D 5 B 0".., 4096) = 4096
> kread(4, " 6 5 0 x 7 E E 3\n 0 x".., 4096) = 4096
> kread(4, " 0 0 x 7 F B D\n 0 x 5".., 4096) = 4096
> kread(4, " 0 x 8 6 C 0\n 0 x 5 6".., 4096) = 4096
> kread(4, " 0 x 5 A 2 F 0 x 8 B C".., 4096) = 4096
> kread(4, " x 5 D 4 6 0 x 8 4 1 C".., 4096) = 4096
> kread(4, " 5 6 5 8\n 0 x 6 0 5 A ".., 4096) = 4096
> kread(4, " C D 7\n 0 x 6 3 7 5 0".., 4096) = 4096
> kread(4, " 2 B 0 x 7 E D 4\n 0 x".., 4096) = 4096
> kread(4, " C\n 0 x 6 A 5 3 0 x 6".., 4096) = 4096
> kread(4, "\n 0 x 6 D 7 0 - 0 x 6 D".., 4096) = 4096
> kread(4, " 0 x 8 9 3 6\n 0 x 7 1 5".., 4096) = 4096
> kread(4, " x 7 4 7 4 0 x 8 D 9 1".., 4096) = 3443
> kread(4, " x 7 4 7 4 0 x 8 D 9 1".., 4096) = 0
> close(4) = 0
> close(4) Err#9 EBADF
> sbrk(0x00000000) = 0x20898000
> sbrk(0x00069000) = 0x20898000
>
>
> It just freezes here.
Can you please run that command in the debugger and see what is going on?
From the symptoms it might be that emacs calls a libc function that
returns malloced memory, and then it tries to do a realloc on that.
A similar problem is solved by the BROKEN_GET_CURRENT_DIR_NAME
in src/s/aix4-2.h
Can you verify if this issue is malloc related?
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#2403; Package
emacs.
(Sat, 07 Mar 2009 04:45:03 GMT)
Full text and
rfc822 format available.
Message #51 received at 2403 <at> emacsbugs.donarmstrong.com (full text, mbox):
Criveti Mihai <crivetimihai <at> gmail.com> writes:
> Emacs is confiugred --with-x=no, ulimits are all unlimited.
>
> cmihai <at> phobos:/home/cmihai/newbuild/emacs/src$ LC_ALL=C ./temacs
> --batch --load loadup bootstrap dump
> Loading loadup.el (source)...
> Using load-path (/home/cmihai/newbuild/emacs/lisp
> /home/cmihai/newbuild/emacs/lisp/emacs-lisp
> /home/cmihai/newbuild/emacs/lisp/language
> /home/cmihai/newbuild/emacs/lisp/international
> /home/cmihai/newbuild/emacs/lisp/textmodes)
> Loading emacs-lisp/byte-run (source)...
> Loading emacs-lisp/backquote (source)...
> Loading subr (source)...
> Loading version.el (source)...
> Loading widget (source)...
> Loading custom (source)...
> Loading emacs-lisp/map-ynp (source)...
> Loading cus-start (source)...
> Loading international/mule (source)...
> Loading international/mule-conf.el (source)...
> Loading env (source)...
> Loading format (source)...
> Loading bindings (source)...
> Loading /home/cmihai/newbuild/emacs/lisp/files.el (source)...
> Loading /home/cmihai/newbuild/emacs/lisp/cus-face.el (source)...
> Loading /home/cmihai/newbuild/emacs/lisp/faces.el (source)...
> Loading /home/cmihai/newbuild/emacs/lisp/minibuffer.el (source)...
> Loading /home/cmihai/newbuild/emacs/lisp/button.el (source)...
> Loading /home/cmihai/newbuild/emacs/lisp/startup.el (source)...
> Lists of integers (garbage collection statistics) are normal output
> while building Emacs; they do not indicate a problem.
> ((120124 . 7654) (6419 . 3) (556 . 148) 484706 22404 (37 . 1) (22 . 5)
> (9678 . 6198))
> Loading /home/cmihai/newbuild/emacs/lisp/ldefs-boot.el (source)...
> ((142077 . 5261) (9199 . 0) (564 . 140) 1422768 22404 (107 . 33) (22 .
> 5) (17962 . 1946))
> Loading /home/cmihai/newbuild/emacs/lisp/abbrev.el (source)...
> Loading /home/cmihai/newbuild/emacs/lisp/simple.el (source)...
> Loading /home/cmihai/newbuild/emacs/lisp/help.el (source)...
> Loading /home/cmihai/newbuild/emacs/lisp/jka-cmpr-hook.el (source)...
> Loading /home/cmihai/newbuild/emacs/lisp/epa-hook.el (source)...
> Loading /home/cmihai/newbuild/emacs/lisp/international/mule-cmds.el (source)...
> Loading /home/cmihai/newbuild/emacs/lisp/case-table.el (source)...
> Loading /home/cmihai/newbuild/emacs/lisp/international/characters.el (source)...
>
>
> Freezes here.
>
> truss ./temacs --batch --load loadup bootstrap
> statx("/home/cmihai/newbuild/emacs/lisp/case-table.el", 0x2FF219D0,
> 128, 010) = 0
> open("/home/cmihai/newbuild/emacs/lisp/case-table.el", O_RDONLY|O_LARGEFILE) = 4
> kread(4, " ; ; ; c a s e - t a b".., 511) = 511
> klseek(4, 0, 0, 0x00000000) = 0
> close(4) = 0
> statx("/home/cmihai/newbuild/emacs/lisp/case-table.el", 0x2FF21490,
> 128, 010) = 0
> open("/home/cmihai/newbuild/emacs/lisp/case-table.el", O_RDONLY|O_LARGEFILE) = 4
> close(4) = 0
> Loading /home/cmihai/newbuild/emacs/lisp/case-table.el
> (source)...kwrite(2, " L o a d i n g / h o m".., 66) = 66
>
> kwrite(2, "\n", 1) = 1
> kfcntl(2, F_GETFL, 0x2FF22FFC) = 67110914
> statx("/home/cmihai/newbuild/emacs/lisp/case-table.el", 0x2FF0C888,
> 128, 010) = 0
> open("/home/cmihai/newbuild/emacs/lisp/case-table.el", O_RDONLY|O_LARGEFILE) = 4
> kread(4, " ; ; ; c a s e - t a b".., 6452) = 6452
> close(4) = 0
> readlink("/home", "", 100) Err#22 EINVAL
> readlink("/home/cmihai", "", 100) Err#22 EINVAL
> readlink("/home/cmihai/newbuild", "", 100) Err#22 EINVAL
> readlink("/home/cmihai/newbuild/emacs", "", 100) Err#22 EINVAL
> readlink("/home/cmihai/newbuild/emacs/lisp", "", 100) Err#22 EINVAL
> readlink("/home/cmihai/newbuild/emacs/lisp/case-table.el", "", 100)
> Err#22 EINVAL
> statx("/home/cmihai/newbuild/emacs/lisp/international/characters.elc",
> 0x2FF219D0, 128, 010) Err#2 ENOENT
> statx("/home/cmihai/newbuild/emacs/lisp/international/characters.elc.gz",
> 0x2FF219D0, 128, 010) Err#2 ENOENT
> statx("/home/cmihai/newbuild/emacs/lisp/international/characters.el",
> 0x2FF219D0, 128, 010) = 0
> open("/home/cmihai/newbuild/emacs/lisp/international/characters.el",
> O_RDONLY|O_LARGEFILE) = 4
> kread(4, " ; ; ; c h a r a c t e".., 511) = 511
> klseek(4, 0, 0, 0x00000000) = 0
> close(4) = 0
> statx("/home/cmihai/newbuild/emacs/lisp/international/characters.el",
> 0x2FF21490, 128, 010) = 0
> open("/home/cmihai/newbuild/emacs/lisp/international/characters.el",
> O_RDONLY|O_LARGEFILE) = 4
> close(4) = 0
> Loading /home/cmihai/newbuild/emacs/lisp/international/characters.el
> (source)...kwrite(2, " L o a d i n g / h o m".., 80) = 80
>
> kwrite(2, "\n", 1) = 1
> kfcntl(2, F_GETFL, 0x2FF22FFC) = 67110914
> statx("/home/cmihai/newbuild/emacs/lisp/international/characters.el",
> 0x2FF0C888, 128, 010) = 0
> open("/home/cmihai/newbuild/emacs/lisp/international/characters.el",
> O_RDONLY|O_LARGEFILE) = 4
> kread(4, " ; ; ; c h a r a c t e".., 38015) = 38015
> close(4) = 0
> readlink("/home", "", 100) Err#22 EINVAL
> readlink("/home/cmihai", "", 100) Err#22 EINVAL
> readlink("/home/cmihai/newbuild", "", 100) Err#22 EINVAL
> readlink("/home/cmihai/newbuild/emacs", "", 100) Err#22 EINVAL
> readlink("/home/cmihai/newbuild/emacs/lisp", "", 100) Err#22 EINVAL
> readlink("/home/cmihai/newbuild/emacs/lisp/international", "", 100)
> Err#22 EINVAL
> readlink("/home/cmihai/newbuild/emacs/lisp/international/characters.el",
> "", 100) Err#22 EINVAL
> statx("/home/cmihai/newbuild/emacs/etc/charsets/GB2312.map",
> 0x2FF20BF0, 128, 010) = 0
> open("/home/cmihai/newbuild/emacs/etc/charsets/GB2312.map",
> O_RDONLY|O_LARGEFILE) = 4
> kfcntl(4, F_GETFL, 0x2FF22FFC) = 67108864
> kioctl(4, 22528, 0x00000000, 0x00000000) Err#25 ENOTTY
> kioctl(4, 22528, 0x00000000, 0x00000000) Err#25 ENOTTY
> kread(4, " # G e n e r a t e d ".., 4096) = 4096
> kread(4, " x 5 F C 5\n 0 x 3 1 5 9".., 4096) = 4096
> kread(4, " 6 D E C\n 0 x 3 4 6 4 ".., 4096) = 4096
> kread(4, " 7 6 E 0 x 5 9 4 9\n 0".., 4096) = 4096
> kread(4, " F 6\n 0 x 3 A 7 9 0 x".., 4096) = 4096
> kread(4, " 5 0 x 8 3 0 E\n 0 x 3".., 4096) = 4096
> kread(4, "\n 0 x 4 1 3 0 0 x 6 D".., 4096) = 4096
> kread(4, " 0 x 6 6 A E\n 0 x 4 4 3".., 4096) = 4096
> kread(4, " x 4 7 4 5 0 x 6 8 6 5".., 4096) = 4096
> kread(4, " 4 A 5 0 0 x 5 E 0 2\n".., 4096) = 4096
> kread(4, " 3 1 6\n 0 x 4 D 5 B 0".., 4096) = 4096
> kread(4, " 6 5 0 x 7 E E 3\n 0 x".., 4096) = 4096
> kread(4, " 0 0 x 7 F B D\n 0 x 5".., 4096) = 4096
> kread(4, " 0 x 8 6 C 0\n 0 x 5 6".., 4096) = 4096
> kread(4, " 0 x 5 A 2 F 0 x 8 B C".., 4096) = 4096
> kread(4, " x 5 D 4 6 0 x 8 4 1 C".., 4096) = 4096
> kread(4, " 5 6 5 8\n 0 x 6 0 5 A ".., 4096) = 4096
> kread(4, " C D 7\n 0 x 6 3 7 5 0".., 4096) = 4096
> kread(4, " 2 B 0 x 7 E D 4\n 0 x".., 4096) = 4096
> kread(4, " C\n 0 x 6 A 5 3 0 x 6".., 4096) = 4096
> kread(4, "\n 0 x 6 D 7 0 - 0 x 6 D".., 4096) = 4096
> kread(4, " 0 x 8 9 3 6\n 0 x 7 1 5".., 4096) = 4096
> kread(4, " x 7 4 7 4 0 x 8 D 9 1".., 4096) = 3443
> kread(4, " x 7 4 7 4 0 x 8 D 9 1".., 4096) = 0
> close(4) = 0
> close(4) Err#9 EBADF
> sbrk(0x00000000) = 0x20898000
> sbrk(0x00069000) = 0x20898000
>
>
> It just freezes here.
Another idea: there is a bug being discussed on the list about loading
international/characters.
Can you please try removing this line:
(load "international/characters")
from emacs/lisp/loadup.el
and see if that helps?
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#2403; Package
emacs.
(Sun, 08 Mar 2009 14:30:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Harald Maier <harald <at> maierh.de>:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>.
(Sun, 08 Mar 2009 14:30:03 GMT)
Full text and
rfc822 format available.
Message #56 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):
Dan Nicolaescu <dann <at> ics.uci.edu> writes:
> Another idea: there is a bug being discussed on the list about loading
> international/characters.
> Can you please try removing this line:
> (load "international/characters")
> from emacs/lisp/loadup.el
> and see if that helps?
Yes, that helps and byte compiling of all the other lisp packages seems
fine. The next problem occurs then in the leim direcotry:
sed -n '/^[^;]/ p' < /install/tools/emacs/leim/leim-ext.el >> leim-list.el
Compiling /install/tools/emacs/leim/ja-dic/ja-dic.el
In toplevel form:
ja-dic/ja-dic.el:47:1:Error: Args out of range: "ãs æ", 1663, 1663
make: *** [/install/tools/emacs/leim/ja-dic/ja-dic.elc] Error 1
If I ignore ja-dic.el in "leim/Makefile" then all went fine but then if
I start emacs I get the following startup error in the function
"set_fontset_font":
Invalid script or charset name: latin
Lisp Backtrace:
"new-fontset" (0x2ff21214)
"setup-default-fontset" (0x2ff21464)
"x-initialize-window-system" (0x2ff215f4)
"byte-code" (0x2ff216d0)
"command-line" (0x2ff21a54)
"normal-top-level" (0x2ff21b70)
Harald
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#2403; Package
emacs.
(Sun, 08 Mar 2009 19:20:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Eli Zaretskii <eliz <at> gnu.org>:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>.
(Sun, 08 Mar 2009 19:20:03 GMT)
Full text and
rfc822 format available.
Message #61 received at 2403 <at> emacsbugs.donarmstrong.com (full text, mbox):
> From: Harald Maier <harald <at> maierh.de>
> Date: Sun, 08 Mar 2009 15:20:52 +0100
> Cc:
>
> Dan Nicolaescu <dann <at> ics.uci.edu> writes:
>
> > Another idea: there is a bug being discussed on the list about loading
> > international/characters.
> > Can you please try removing this line:
> > (load "international/characters")
> > from emacs/lisp/loadup.el
> > and see if that helps?
>
> Yes, that helps and byte compiling of all the other lisp packages seems
> fine.
> [...]
> but then if
> I start emacs I get the following startup error in the function
>
> "set_fontset_font":
>
> Invalid script or charset name: latin
This is expected, since lisp/international/characters.el is not
loaded.
Can you try loading it at startup time? Something like this:
emacs -Q -l characters.el
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#2403; Package
emacs.
(Mon, 09 Mar 2009 18:10:04 GMT)
Full text and
rfc822 format available.
Message #64 received at 2403 <at> emacsbugs.donarmstrong.com (full text, mbox):
Harald Maier <harald <at> maierh.de> writes:
> Dan Nicolaescu <dann <at> ics.uci.edu> writes:
>
> > Another idea: there is a bug being discussed on the list about loading
> > international/characters.
> > Can you please try removing this line:
> > (load "international/characters")
> > from emacs/lisp/loadup.el
> > and see if that helps?
>
> Yes, that helps and byte compiling of all the other lisp packages seems
> fine.
A fix was installed yesterday for international/characters. Can you
please try uncommenting (load "international/characters") and see if it
works better now?
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#2403; Package
emacs.
(Tue, 10 Mar 2009 06:25:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Criveti Mihai <crivetimihai <at> gmail.com>:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>.
(Tue, 10 Mar 2009 06:25:03 GMT)
Full text and
rfc822 format available.
Message #69 received at 2403 <at> emacsbugs.donarmstrong.com (full text, mbox):
Loading /home/cmihai/newbuild/emacs/lisp/international/mule-cmds.el (source)...
Loading /home/cmihai/newbuild/emacs/lisp/case-table.el (source)...
Loading /home/cmihai/newbuild/emacs/lisp/international/characters.el (source)...
---------------------------------------------------------------------------------------------------------
Still hangs after the cvs update at loading
international/characters.el for me. AIX 5.3, XL C 10.1.
./configure --with-x=no; make bootstrap (hangs).
On Mon, Mar 9, 2009 at 8:02 PM, Dan Nicolaescu <dann <at> ics.uci.edu> wrote:
> Harald Maier <harald <at> maierh.de> writes:
>
> > Dan Nicolaescu <dann <at> ics.uci.edu> writes:
> >
> > > Another idea: there is a bug being discussed on the list about loading
> > > international/characters.
> > > Can you please try removing this line:
> > > (load "international/characters")
> > > from emacs/lisp/loadup.el
> > > and see if that helps?
> >
> > Yes, that helps and byte compiling of all the other lisp packages seems
> > fine.
>
> A fix was installed yesterday for international/characters. Can you
> please try uncommenting (load "international/characters") and see if it
> works better now?
>
>
>
>
>
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#2403; Package
emacs.
(Tue, 10 Mar 2009 19:55:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Eli Zaretskii <eliz <at> gnu.org>:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>.
(Tue, 10 Mar 2009 19:55:04 GMT)
Full text and
rfc822 format available.
Message #74 received at 2403 <at> emacsbugs.donarmstrong.com (full text, mbox):
> Date: Tue, 10 Mar 2009 08:18:12 +0200
> From: Criveti Mihai <crivetimihai <at> gmail.com>
> Cc:
>
> Loading /home/cmihai/newbuild/emacs/lisp/international/mule-cmds.el (source)...
> Loading /home/cmihai/newbuild/emacs/lisp/case-table.el (source)...
> Loading /home/cmihai/newbuild/emacs/lisp/international/characters.el (source)...
> ---------------------------------------------------------------------------------------------------------
>
> Still hangs after the cvs update at loading
> international/characters.el for me. AIX 5.3, XL C 10.1.
> ./configure --with-x=no; make bootstrap (hangs).
Can you "kill -ABRT" temacs when it hangs like that, then show the
traceback from the core file produced by that? (You may need to say
something like "ulimit -c unlimited" to allow unlimited size of core
files.)
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#2403; Package
emacs.
(Wed, 11 Mar 2009 05:40:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Harald Maier <harald <at> maierh.de>:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>.
(Wed, 11 Mar 2009 05:40:04 GMT)
Full text and
rfc822 format available.
Message #79 received at 2403 <at> emacsbugs.donarmstrong.com (full text, mbox):
Dan Nicolaescu <dann <at> ics.uci.edu> writes:
> Harald Maier <harald <at> maierh.de> writes:
>
> > Dan Nicolaescu <dann <at> ics.uci.edu> writes:
> >
> > > Another idea: there is a bug being discussed on the list about loading
> > > international/characters.
> > > Can you please try removing this line:
> > > (load "international/characters")
> > > from emacs/lisp/loadup.el
> > > and see if that helps?
> >
> > Yes, that helps and byte compiling of all the other lisp packages seems
> > fine.
>
> A fix was installed yesterday for international/characters. Can you
> please try uncommenting (load "international/characters") and see if it
> works better now?
Hello Dan,
unfortunately, it doesn't work. TEmacs still is in an infinite loop to
due a cyclic reference in the file "alloc.c". The gcpro data type below
points to itself in the next element (see too my previous report).
Eli pointed out that this is maybe a problem with the stack size. I
increased the stack size but the problem still exists. Stefan suggested
to put in some "eassert" but I don't have a clue where to put in this
assertion functions.
The questions are why does it happen only under AIX 5.2/5.3 and why does
it happen in characters.el. If I take out loading characters.el, emacs
builds and also the "terminal" emacs seems to work.
Harald
Program received signal SIGTSTP, Stopped (user).
[Switching to Thread 1]
Fgarbage_collect () at alloc.c:5108
(gdb) bt
#0 Fgarbage_collect () at alloc.c:5108
#1 0x10060214 in Ffuncall (nargs=3, args=0x2ff20bf4) at eval.c:2978
#2 0x10060a0c in call2 (fn=14, arg1=540510209, arg2=540510209) at
eval.c:2847
#3 0x1007881c in map_charset_for_dump (c_function=0,
function=540705105, arg=792, from=7, to=544894764) at charset.c:712
#4 0x10078be0 in map_charset_chars (c_function=0, function=540705105,
arg=792, charset=0x204d37c8, from=8481, to=32382) at charset.c:766
#5 0x10079058 in Fmap_charset_chars (function=540705105,
charset=541497681, arg=792, from_code=540510209, to_code=540510209) at
charset.c:861
#6 0x1005f484 in Feval (form=545329461) at eval.c:2389
#7 0x100156a8 in readevalloop (readcharfun=540553732, stream=0x0,
sourcename=544177635, evalfun=@0x2014e068: 0x1005ee58 <Feval>,
printflag=0, unibyte=0, readfun=540510209, start=540510209,
end=540510209) at lread.c:1782
#8 0x10015cc8 in Feval_buffer (buffer=14, printflag=540510209,
filename=544219395, unibyte=540510209, do_allow_print=539058292) at
lread.c:1845
#9 0x1005f484 in Feval (form=541151925) at eval.c:2389
#10 0x1005fb68 in Fprogn (args=541152005) at eval.c:449
#11 0x10063770 in Flet (args=541151645) at eval.c:1089
#12 0x1005f690 in Feval (form=541151565) at eval.c:2322
#13 0x100610a4 in Funwind_protect (args=541152013) at eval.c:1353
#14 0x1005f690 in Feval (form=541151557) at eval.c:2322
#15 0x1005fb68 in Fprogn (args=541152085) at eval.c:449
#16 0x10063994 in FletX (args=541151381) at eval.c:1033
#17 0x1005f690 in Feval (form=541153189) at eval.c:2322
#18 0x1005fb68 in Fprogn (args=541150261) at eval.c:449
#19 0x10063b70 in Fif (args=541153069) at eval.c:398
#20 0x1005f690 in Feval (form=541153029) at eval.c:2322
#21 0x1005fb68 in Fprogn (args=541150269) at eval.c:449
#22 0x1005fe54 in funcall_lambda (fun=541150277, nargs=4,
arg_vector=0x2ff21690) at eval.c:3224
#23 0x100606d0 in Ffuncall (nargs=5, args=0x20442969) at eval.c:3101
#24 0x10060908 in call4 (fn=14, arg1=540510209, arg2=540510209, arg3=7,
arg4=544894764) at eval.c:2894
#25 0x10016ca8 in Fload (file=544222387, noerror=540510209,
nomessage=540510209, nosuffix=538291768, must_suffix=25) at lread.c:1205
#26 0x1005f484 in Feval (form=545333781) at eval.c:2389
#27 0x100156a8 in readevalloop (readcharfun=540671769,
stream=0xf05423a0, sourcename=540843795, evalfun=@0x2014e068: 0x1005ee58
<Feval>, printflag=0, unibyte=0, readfun=540510209, start=540510209,
end=540510209) at lread.c:1782
#28 0x10016ecc in Fload (file=540843667, noerror=1, nomessage=540510209,
nosuffix=0, must_suffix=24) at lread.c:1252
#29 0x1005f484 in Feval (form=540495077) at eval.c:2389
#30 0x1008bc04 in top_level_2 () at keyboard.c:1366
#31 0x1005e3d4 in internal_condition_case (bfun=@0x20152184: 0x1008bbec
<top_level_2>, handlers=540581009, hfun=@0x2015216c: 0x10090750
<cmd_error>) at eval.c:1511
#32 0x100903bc in top_level_1 () at keyboard.c:1374
#33 0x1005e510 in internal_catch (tag=14, func=@0x20152190: 0x10090384
<top_level_1>, arg=540510209) at eval.c:1247
#34 0x10090490 in command_loop () at keyboard.c:1329
#35 0x10090990 in recursive_edit_1 () at keyboard.c:951
#36 0x10090b48 in Frecursive_edit () at keyboard.c:1013
#37 0x10002d34 in main (argc=540671625, argv=0x2ff2219c) at emacs.c:1852
Lisp Backtrace:
"map-charset-chars" (0x2ff20da8)
"eval-buffer" (0x2ff20f80)
"let" (0x2ff210d8)
"unwind-protect" (0x2ff211d8)
"let*" (0x2ff21358)
"if" (0x2ff214b0)
"load-with-code-conversion" (0x2ff21690)
"load" (0x2ff218d8)
"load" (0x2ff21bf8)
(gdb) p tail
$1 = (struct gcpro *) 0x2ff20c4c
(gdb) p *tail
$2 = {
next = 0x2ff20c4c,
var = 0x2ff20c48,
nvars = 1
}
--- alloc.c: 5101 ---
#if (GC_MARK_STACK == GC_MAKE_GCPROS_NOOPS \
|| GC_MARK_STACK == GC_MARK_STACK_CHECK_GCPROS)
mark_stack ();
#else
{
register struct gcpro *tail;
=> for (tail = gcprolist; tail; tail = tail->next)
for (i = 0; i < tail->nvars; i++)
mark_object (tail->var[i]);
}
#endif
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#2403; Package
emacs.
(Wed, 18 Mar 2009 16:35:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Raúl Porcel <armin76 <at> gentoo.org>:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>.
(Wed, 18 Mar 2009 16:35:02 GMT)
Full text and
rfc822 format available.
Message #84 received at 2403 <at> emacsbugs.donarmstrong.com (full text, mbox):
Hi guys,
I get the same hang on Linux, but running under the SuperH architecture.
Our downstream bug is https://bugs.gentoo.org/show_bug.cgi?id=262359#c4
And if you read that, you will see i've tracked it to this commit:
http://git.savannah.gnu.org/gitweb/?p=emacs.git;a=commitdiff;h=2cca1253c9cc30fc7be3231b478e8b6859ef7600
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#2403; Package
emacs.
(Thu, 19 Mar 2009 19:45:07 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
rms <at> gnu.org:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>.
(Thu, 19 Mar 2009 19:45:07 GMT)
Full text and
rfc822 format available.
Message #89 received at 2403 <at> emacsbugs.donarmstrong.com (full text, mbox):
I get the same hang on Linux,
I think you mean the GNU/Linux system. Linux alone is not a
sufficient platform to run Emacs.
Thanks for reporting the bug.
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#2403; Package
emacs.
(Tue, 24 Mar 2009 11:15:05 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Pierre Poissinger <pierre.poissinger <at> gmail.com>:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>.
(Tue, 24 Mar 2009 11:15:05 GMT)
Full text and
rfc822 format available.
Message #94 received at 2403 <at> emacsbugs.donarmstrong.com (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
I also did a git bisect but on AIX and end up with same "problematic" commit:
------
2cca1253c9cc30fc7be3231b478e8b6859ef7600 is first bad commit
commit 2cca1253c9cc30fc7be3231b478e8b6859ef7600
Author: Kenichi Handa <handa <at> m17n.org>
Date: Thu Nov 27 08:02:28 2008 +0000
Set inhibit-load-charset-map to t while preloading
files.
------
Reverting partially this change-set allowed to finish bootstrap and
install on AIX (5.2)
[Attached the partial revert I made]
Cheers,
Pierre
--
>>> horsemen = ['war', 'pestilence', 'famine']
>>> horsemen.append('Powerbuilder')
[emacs-23-git.aix-build.patch (text/x-patch, attachment)]
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#2403; Package
emacs.
(Sat, 28 Mar 2009 15:50:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Raúl Porcel <armin76 <at> gentoo.org>:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>.
(Sat, 28 Mar 2009 15:50:03 GMT)
Full text and
rfc822 format available.
Message #99 received at 2403 <at> emacsbugs.donarmstrong.com (full text, mbox):
Reverting the commit, it goes until this place, as i already said on
comment #4 on our downstream bug.
Compiling quail/quick-cns.el
Fatal error (11)make[2]: *** [quail/quick-cns.elc] Segmentation fault
make[2]: Leaving directory `/root/cvs/emacs/leim'
make[1]: *** [leim] Error 2
make[1]: Leaving directory `/root/cvs/emacs'
make: *** [bootstrap] Error 2
P.S.: Thank you very much for your comment, Mr. Stallman, I'm pretty
sure it's going to fix the problem on your software.
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#2403; Package
emacs.
(Mon, 30 Mar 2009 10:25:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Pierre Poissinger <pierre.poissinger <at> gmail.com>:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>.
(Mon, 30 Mar 2009 10:25:04 GMT)
Full text and
rfc822 format available.
Message #104 received at 2403 <at> emacsbugs.donarmstrong.com (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
Took time to trace/debug with the help of Pascal Stenuit: The bug and
pattern seems to be a leak in GC due to a missing GCUNPRO...
This result in a unclean gcprolist in AIX (I do think the bug is "all
arch", just badly visible in AIX and some specific GNU/Linux arch -
other archs will just leak)...
Here come the patch - applied to a clean today checkout and passed the
bootstrap of "characters" just fine
Regs,
Pierre
--
>>> horsemen = ['war', 'pestilence', 'famine']
>>> horsemen.append('Powerbuilder')
[emacs-fix-missing-gc.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#2403; Package
emacs.
(Mon, 30 Mar 2009 15:50:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stefan Monnier <monnier <at> iro.umontreal.ca>:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>.
(Mon, 30 Mar 2009 15:50:03 GMT)
Full text and
rfc822 format available.
Message #109 received at 2403 <at> emacsbugs.donarmstrong.com (full text, mbox):
> Took time to trace/debug with the help of Pascal Stenuit: The bug and
> pattern seems to be a leak in GC due to a missing GCUNPRO...
Than you very much, installed.
> This result in a unclean gcprolist in AIX (I do think the bug is "all
> arch", just badly visible in AIX and some specific GNU/Linux arch -
> other archs will just leak)...
Other arches don't use GCPROs at all, instead they conservatively scan
the whole stack. They do that by setting
#define GC_MARK_STACK GC_MAKE_GCPROS_NOOPS
in the corresponding emacs/src/s/*.h. This is the preferred way to
function, so if you can test it and confirm that it works as well under
AIX, we could set it for that OS as well.
Stefan
bug closed, send any further explanations to Harald Maier <harald <at> maierh.de>
Request was from
Stefan Monnier <monnier <at> iro.umontreal.ca>
to
control <at> emacsbugs.donarmstrong.com.
(Mon, 30 Mar 2009 16:10:04 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#2403; Package
emacs.
(Mon, 30 Mar 2009 18:20:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Ulrich Mueller <ulm <at> gentoo.org>:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>.
(Mon, 30 Mar 2009 18:20:03 GMT)
Full text and
rfc822 format available.
Message #116 received at 2403 <at> emacsbugs.donarmstrong.com (full text, mbox):
> Other arches don't use GCPROs at all, instead they conservatively
> scan the whole stack. They do that by setting
> #define GC_MARK_STACK GC_MAKE_GCPROS_NOOPS
> in the corresponding emacs/src/s/*.h. This is the preferred way to
> function, [...]
Since almost all other arches do it, I wonder if this shouldn't be
done for GNU/Linux on SuperH, too. That is, add "|| defined __sh__"
to the large #if statement in src/s/gnu-linux.h .
Ulrich
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#2403; Package
emacs.
(Mon, 30 Mar 2009 22:05:05 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Pierre Poissinger <pierre.poissinger <at> gmail.com>:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>.
(Mon, 30 Mar 2009 22:05:05 GMT)
Full text and
rfc822 format available.
Message #121 received at 2403 <at> emacsbugs.donarmstrong.com (full text, mbox):
[Message part 1 (text/plain, inline)]
> Than you very much, installed.
You are welcome
> Other arches don't use GCPROs at all, instead they conservatively scan
> the whole stack. They do that by setting
>
> #define GC_MARK_STACK GC_MAKE_GCPROS_NOOPS
>
> in the corresponding emacs/src/s/*.h. This is the preferred way to
> function, so if you can test it and confirm that it works as well under
> AIX, we could set it for that OS as well.
Oups - I actually didn't look so far - readed that same bug hit
GNU/Linux on Super7 so didn't look further...
Since I was in a good mood (Emacs 23 working on my boxes) I took the
liberty to also define GC_SETJMP_WORKS since I saw it next to
GC_MARK_STACK [and ok, I felt lucky...]
So far so good - full build/bootstrapping went fine from latest git
master - basic testing don't show regressions - will see tomorrow if
something fishy pops during work, otherwise looks fine.
In case of need: the compiler used is a gcc-2.9-aix51 on a good old
aix 5.2 - didn't have the courage to try the outdated xlc...
Notes:
* To be able to build emacs with X support (I was really in a good
mood): Had to correct 2 files with "old compilers are grumpy" errors
[0001-gcc-2.9-aix51-020209-compile-fix.patch]
* The actual change I made to src/s/aix-4-2.h
[0002-GC-test-for-AIX.patch]
Regs,
Pierre
--
>>> horsemen = ['war', 'pestilence', 'famine']
>>> horsemen.append('Powerbuilder')
[0001-gcc-2.9-aix51-020209-compile-fix.patch (text/x-patch, attachment)]
[0002-GC-test-for-AIX.patch (text/x-patch, attachment)]
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#2403; Package
emacs.
(Tue, 31 Mar 2009 02:05:06 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stefan Monnier <monnier <at> iro.umontreal.ca>:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>.
(Tue, 31 Mar 2009 02:05:06 GMT)
Full text and
rfc822 format available.
Message #126 received at 2403 <at> emacsbugs.donarmstrong.com (full text, mbox):
> Since almost all other arches do it, I wonder if this shouldn't be
> done for GNU/Linux on SuperH, too. That is, add "|| defined __sh__"
> to the large #if statement in src/s/gnu-linux.h .
Yes, it's probably a good idea, but we first need to check.
If you have access to such an arch, please try it out.
Stefan
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#2403; Package
emacs.
(Tue, 31 Mar 2009 13:40:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Raúl Porcel <armin76 <at> gentoo.org>:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>.
(Tue, 31 Mar 2009 13:40:04 GMT)
Full text and
rfc822 format available.
Message #131 received at 2403 <at> emacsbugs.donarmstrong.com (full text, mbox):
Doing what Ulrich recommended makes it not hang on SuperH. However it
fails with a Bus error later on.
I'll try some stuff and submit a new bug for that one.
This is the error i get now:
Compiling quail/quick-cns.el
Fatal error (7)make[2]: *** [quail/quick-cns.elc] Bus error
make[2]: Leaving directory `/root/emacs/leim'
make[1]: *** [leim] Error 2
Unaligned accesses are fatal on sh like on sparc. But as I said, i'll
file another bug.
Thanks Pierre for finding out this stuff :)
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#2403; Package
emacs.
(Sat, 04 Apr 2009 21:50:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Ulrich Mueller <ulm <at> gentoo.org>:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>.
(Sat, 04 Apr 2009 21:50:03 GMT)
Full text and
rfc822 format available.
Message #136 received at 2403 <at> emacsbugs.donarmstrong.com (full text, mbox):
[Message part 1 (text/plain, inline)]
>> Since almost all other arches do it, I wonder if this shouldn't be
>> done for GNU/Linux on SuperH, too. That is, add "|| defined __sh__"
>> to the large #if statement in src/s/gnu-linux.h .
> Yes, it's probably a good idea, but we first need to check.
> If you have access to such an arch, please try it out.
Gentoo SuperH architecture team has tested it, and they find that
Emacs builds and works with that definition added.
Whereas without it, the build on SuperH fails with a bus error, as
mentioned on this bug report before.
So please commit attached patch.
2009-04-04 Ulrich Mueller <ulm <at> gentoo.org>
* s/gnu-linux.h: Make GCPROs and UNGCPRO no-ops also on SuperH.
[emacs-23.0.92-sh.patch (text/plain, inline)]
--- emacs-orig/src/s/gnu-linux.h
+++ emacs/src/s/gnu-linux.h
@@ -258,7 +258,7 @@
#if defined __i386__ || defined __sparc__ || defined __mc68000__ \
|| defined __alpha__ || defined __mips__ || defined __s390__ \
|| defined __arm__ || defined __powerpc__ || defined __amd64__ \
- || defined __ia64__
+ || defined __ia64__ || defined __sh__
#define GC_SETJMP_WORKS 1
#define GC_MARK_STACK GC_MAKE_GCPROS_NOOPS
#ifdef __mc68000__
Tags added: patch
Request was from
Ulrich Mueller <ulm <at> gentoo.org>
to
control <at> emacsbugs.donarmstrong.com.
(Fri, 17 Apr 2009 19:40:04 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#2403; Package
emacs.
(Fri, 17 Apr 2009 19:45:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Ulrich Mueller <ulm <at> gentoo.org>:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>.
(Fri, 17 Apr 2009 19:45:03 GMT)
Full text and
rfc822 format available.
Message #143 received at 2403 <at> emacsbugs.donarmstrong.com (full text, mbox):
>>>>> On Sat, 4 Apr 2009, Ulrich Mueller wrote:
>>> Since almost all other arches do it, I wonder if this shouldn't be
>>> done for GNU/Linux on SuperH, too. That is, add "|| defined __sh__"
>>> to the large #if statement in src/s/gnu-linux.h .
>> Yes, it's probably a good idea, but we first need to check.
>> If you have access to such an arch, please try it out.
> Gentoo SuperH architecture team has tested it, and they find that
> Emacs builds and works with that definition added.
> So please commit attached patch.
Any reason why this cannot be committed?
<http://debbugs.gnu.org/cgi/bugreport.cgi?msg=136;filename=emacs-23.0.92-sh.patch;att=1;bug=2403>
Ulrich
bug reopened, originator set to Ulrich Mueller <ulm <at> gentoo.org>.
Request was from
Ulrich Mueller <ulm <at> gentoo.org>
to
control <at> emacsbugs.donarmstrong.com.
(Fri, 17 Apr 2009 19:50:04 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#2403; Package
emacs.
(Tue, 28 Apr 2009 14:15:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Raúl Porcel <armin76 <at> gentoo.org>:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>.
(Tue, 28 Apr 2009 14:15:04 GMT)
Full text and
rfc822 format available.
Message #150 received at 2403 <at> emacsbugs.donarmstrong.com (full text, mbox):
Ulrich Mueller wrote:
>>>>>> On Sat, 4 Apr 2009, Ulrich Mueller wrote:
>
>>>> Since almost all other arches do it, I wonder if this shouldn't be
>>>> done for GNU/Linux on SuperH, too. That is, add "|| defined __sh__"
>>>> to the large #if statement in src/s/gnu-linux.h .
>
>>> Yes, it's probably a good idea, but we first need to check.
>>> If you have access to such an arch, please try it out.
>
>> Gentoo SuperH architecture team has tested it, and they find that
>> Emacs builds and works with that definition added.
>
>> So please commit attached patch.
>
> Any reason why this cannot be committed?
> <http://debbugs.gnu.org/cgi/bugreport.cgi?msg=136;filename=emacs-23.0.92-sh.patch;att=1;bug=2403>
>
> Ulrich
Same question here
bug closed, send any further explanations to Ulrich Mueller <ulm <at> gentoo.org>
Request was from
Ulrich Mueller <ulm <at> gentoo.org>
to
control <at> emacsbugs.donarmstrong.com.
(Thu, 21 May 2009 20:25:07 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> emacsbugs.donarmstrong.com.
(Fri, 19 Jun 2009 14:24:13 GMT)
Full text and
rfc822 format available.
This bug report was last modified 16 years and 82 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.