unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Andy Wingo <wingo@pobox.com>
To: szgyg <szgyg@ludens.elte.hu>
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: Guile HEAD on Cygwin-1.7
Date: Sun, 28 Jun 2009 23:09:37 +0200	[thread overview]
Message-ID: <m3ws6wysj2.fsf@pobox.com> (raw)
In-Reply-To: <4A462061.30101@ludens.elte.hu> (szgyg@ludens.elte.hu's message of "Sat, 27 Jun 2009 15:36:34 +0200")

Hi szgyg,

On Sat 27 Jun 2009 15:36, szgyg <szgyg@ludens.elte.hu> writes:

> Andy Wingo wrote:
>> On Thu 18 Jun 2009 09:33, szgyg writes:
>>> make[2]: Entering directory `/home/szgyg/src/GIT/guile/=build/module'
>>> GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o 
>>> "ice-9/psyntax-pp.go" "../../module/ice-9/psyntax-pp.scm"
>>> wrote `ice-9/psyntax-pp.go'
>>
>> I wonder why it's regenerating psyntax-pp.scm. It shouldn't, psyntax.scm
>> should be newer than psyntax-pp.scm.
>
> Git doesn't preserve timestamps, so either file can be the newer after a
> fresh checkout.

Ah, I didn't know this. Hmm, this is a problem. Perhaps we need some
auxiliary Makefile help to make sure psyntax-pp is seen as fresh after a
fresh checkout.

> --- T.scm ---
> (define *old-stack-level* (and=> (memq 'stack (debug-options)) cadr))
> (debug-set! stack (* 2 *old-stack-level*))
> (display #t)
> -------------
>
> $ guile -q --debug -s T.scm
>
> Backtrace:
> In ../../module/ice-9/boot-9.scm:
>  874: 0* [#<program 100d7500 ()>]
> In unknown file:
>    ?: 1* [primitive-load "T.scm"]
> In ../../module/ice-9/psyntax-pp.scm:
> 8216: 2* [# #]
>
> ERROR: Stack overflow

Interesting. Is this the full backtrace? What were your CFLAGS when
compiling Guile?

> in
> commit e33779e3b84b4822b4d51562d7c4f1e65408151d
> Date:   Thu Jun 25 23:24:57 2009 +0100
>     Revert "* FAQ: New file."
>
> The stack can grow a little, but not so much. Works with the factor 1.3,
> but not with 1.4 (*old-stack-level* is  416784).

I don't understand -- do you mean to say that T.scm works if "(* 2" is
replaced with "(* 1.3"?

>>> make[1]: Entering directory `/home/szgyg/src/GIT/guile/=build'
>>> make  check-TESTS
>>> make[2]: Entering directory `/home/szgyg/src/GIT/guile/=build'
>>> Testing /home/szgyg/src/GIT/guile/=build/meta/guile ...
>>> with GUILE_LOAD_PATH=/home/szgyg/src/GIT/guile/test-suite
>>> /bin/sh: line 5:  3944 Segmentation fault      (core dumped) ${dir}$tst
>>> FAIL: check-guile
>>
>> To me that looks like a segfault in your shell.

Hmm, I guess not ;-)

> Program received signal SIGSEGV, Segmentation fault.
> [Switching to thread 3544.0xc1c]
> 0x6aac70d9 in scm_read_delimited_x (delims=0x100e6400, str=0x102f90a0,
>     gobble=0x104, port=0x102bd398, start=0x204, end=0x204)
>     at ../../libguile/inline.h:307
> 307           if (scm_fill_input (port) == EOF)

What exactly is segfaulting here? All of the vars look fine, and in your
printouts. This seems just to be a problem running Guile, perhaps not
specific to the tests. Can you run meta/guile and it works? If not,
meta/gdb-uninstalled-guile might be useful.

Andy
-- 
http://wingolog.org/




  reply	other threads:[~2009-06-28 21:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-18  7:33 Guile HEAD on Cygwin-1.7 szgyg
2009-06-20 11:10 ` Andy Wingo
2009-06-27 13:36   ` szgyg
2009-06-28 21:09     ` Andy Wingo [this message]
2009-07-07 15:53       ` szgyg
2009-07-23 20:59         ` Andy Wingo
2009-07-25 16:14           ` szgyg
2009-07-26 13:12             ` Merging libguile-i18n with libguile Ludovic Courtès
2009-07-26 19:25               ` Andy Wingo
2009-07-27 22:56               ` Neil Jerram

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3ws6wysj2.fsf@pobox.com \
    --to=wingo@pobox.com \
    --cc=guile-devel@gnu.org \
    --cc=szgyg@ludens.elte.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).