Re: Compile failure on IRIX 6.5

Re: Compile failure on IRIX 6.5

[Richard Stallman]

This looks like stack overflow printing an object that contains
a pointer to itself.  Could you verify this was stack overflow?

What is the value of Vprint_length?

    Also, run-time debugging log with dbx (gdb won't work), manually newlined:

Why won't GDB work?  Have you tried installing the latest GDB?
If that still fails, maybe it is a GDB bug--would you please report
the GDB bug?

Anyway, it is not a bug that Emacs can crash if you print a cyclic
structure with the wrong settings.  The question is, why is that
happening?  The crucial point for finding the Emacs bug is, what Lisp
program is trying to print something, and why, and why is that object
such as to get an error in printing.  For this, it would be useful to
look at the log of output from bootstrapping shortly before the crash.

Re: Compile failure on IRIX 6.5

[Daichi Kawahata]

On Mon, 21 Feb 2005 05:21:59 -0500
Richard Stallman wrote:

> This looks like stack overflow printing an object that contains
> a pointer to itself.  Could you verify this was stack overflow?

I'm afraid I have no idea what can be considered stack overflow.

> What is the value of Vprint_length?

Although I don't know at where step of Vprint_length is required,

$ dbx ./bootstrap-emacs 
[...]
(dbx) run -q
Process 898774 (bootstrap-emacs) started
[...]
Process 898774 (bootstrap-emacs) stopped on signal SIGSEGV:
  Segmentation violation (handler sig_fixup_mask) at
  [print_object:1485 +0x8,0x101a622c]
1485  float_to_string (pigbuf, XFLOAT_DATA (obj));
(dbx) p Vprint_length
272150529 
(dbx)

> Anyway, it is not a bug that Emacs can crash if you print a
> cyclic structure with the wrong settings.

Could you tell me wrong settings of what/mine?

> The question is, why is that happening?  The crucial point for
> finding the Emacs bug is, what Lisp program is trying to print
> something,

Does that mean built-in/included Lisp program? as a total beginner,
I'd think option '-q' has Emacs not to take any initial/external
file.

> and why, and why is that object such as to get an error in
> printing.  For this, it would be useful to look at the log of
> output from bootstrapping shortly before the crash.

If it's allowed, I'll attach entire make.log, well I don't know
log of which (in the GDB or make process) you mentioned, but as
far as make process is concerned, output log just before the
crash is,

[...]
Dumping under names emacs and emacs-22.0.50
73668 pure bytes used
mv -f emacs bootstrap-emacs
gmake[1]: Leaving directory `/opt/src/i18n/emacs/src'
(cd lisp; gmake  bootstrap EMACS=../src/bootstrap-emacs)
gmake[1]: Entering directory `/opt/src/i18n/emacs/lisp'
wd=/opt/src/i18n/emacs/lisp; subdirs=`(cd $wd; find . -type d -print)`;
for file in $subdirs; do case $file in */Old | */RCS | */CVS | */CVS/*
| */.* | */. */* | */=* ) ;; *) wins="$wins $wd/$file" ;; esac; done; \
| for file in $wins; do \
   /opt/src/i18n/emacs/lisp/../update-subdirs $file; \
done;
wd=/opt/src/i18n/emacs/lisp; subdirs=`(cd $wd; find . -type d -print)`;
for file in $subdirs; do case $file in */Old | */RCS | */CVS | */CVS/*
| */.* | */. */* | */=* ) ;; *) wins="$wins $wd/$file" ;; esac; done; \
| echo Directories: $wins; \
../src/bootstrap-emacs -batch --no-site-file --multibyte -l autoload --
eval '(setq generated-autoload-file "/opt/src/i18n/emacs/lisp/
loaddefs.el")' -f batc h-update-autoloads $wins Directories: /opt/src/
i18n/emacs/lisp/. /opt/src/i18n/emacs/lisp/./net /opt/src/i18n/emacs/
lisp/./url /opt/src/i18n/emacs/lisp/./calc /opt/src/i18n/emacs/l isp/./
gnus /opt/src/i18n/emacs/lisp/./mail /opt/src/i18n/emacs/lisp/./mh-e /
opt/src/i18n/emacs/lisp/./play /opt/src/i18n/emacs/lisp/./term /opt/src/
i18n/em acs/lisp/./emacs-lisp /opt/src/i18n/emacs/lisp/./eshell /opt/
src/i18n/emacs/lisp/./calendar /opt/src/i18n/emacs/lisp/./
international /opt/src/i18n/emacs/li sp/./emulation /opt/src/i18n/emacs/
lisp/./language /opt/src/i18n/emacs/lisp/./textmodes /opt/src/i18n/
emacs/lisp/./progmodes /opt/src/i18n/emacs/lisp/./obs olete /opt/src/
i18n/emacs/lisp/./toolbar Fatal error (11)gmake[1]: *** [autoloads]
Segmentation fault (core dumped) gmake[1]: Leaving directory `/opt/src/
i18n/emacs/lisp' gmake: *** [bootstrap-build] Error 2

Regards,
-- 
Daichi

Re: Compile failure on IRIX 6.5

[Richard Stallman]

You must not expect us to intuit where the cause of this bug is.  That
is very hard.  If you want to fix this bug, you will have to debug it.
Nobody else can debug it, unless he can make it fail.

You may as well start by reading lisp.h and learning the format of
Lisp objects, so that you can figure out what each object mean.

    I'm afraid I have no idea what can be considered stack overflow.

Look at the stack pointer; you'll have to learn about the machine's
conventions to see what's a valid stack pointer value.

    (dbx) p Vprint_length
    272150529 

What does that number mean as a Lisp Object on your platform?
Is it nil?  Look in Qnil and see what you find.

    > The question is, why is that happening?  The crucial point for
    > finding the Emacs bug is, what Lisp program is trying to print
    > something,

    Does that mean built-in/included Lisp program? as a total beginner,
    I'd think option '-q' has Emacs not to take any initial/external
    file.

The task at hand is to find out what's happening.
Lisp code is being run.  What code, and why?