From: Neil Jerram <neil@ossau.uklinux.net>
To: Roger Mc Murtrie <ROGERMC@IINET.NET.AU>
Cc: Guile Bugs <bug-guile@gnu.org>
Subject: Re: Mac PowerBookG4 OS X 10.4.11 (Tiger) guile test results
Date: Thu, 10 Jan 2008 22:40:37 +0000 [thread overview]
Message-ID: <87y7ax1eze.fsf@ossau.uklinux.net> (raw)
In-Reply-To: <EA79D2A8-EDBB-4D19-AE80-5962D562CB09@IINET.NET.AU> (Roger Mc Murtrie's message of "Fri, 11 Jan 2008 06:36:49 +1100")
Roger Mc Murtrie <ROGERMC@IINET.NET.AU> writes:
> Still fails with 40000:
Yes, but not because of stack overflow. So the doubling of the stack
size was successful.
> sizeof long: 4
As hoped. The point is that most of the data that Guile puts on the C
stack are pointers or pointer-like. Hence the size of the stack (for
a given operation) on a 64-bit OS will be almost twice the size on a
32-bit OS.
But the max stack size that Guile allows is the value of the "stack"
debug option multiplied by sizeof(long), and it seems that
sizeof(long) is the same on 64-bit OSs (or at least on yours) as on
32-bit.
I think a good fix would be to replace uses of SCM_STACK_LIMIT by
(SCM_STACK_LIMIT * sizeof(SCM)) / sizeof(SCM_STACKITEM). (And then
the 20000 -> 40000 change can should be reverted.) Patch (against
1.8.x CVS) is below. Opinions?
> /Users/Roger/Downloads/guile-1.8.3/srfi/srfi-1.scm:223:1: In procedure
> dynamic-link in expression (load-extension "libguile-srfi-srfi-1-v-3"
> "scm_init_srfi_1"):
> /Users/Roger/Downloads/guile-1.8.3/srfi/srfi-1.scm:223:1: file:
> "libguile-srfi-srfi-1-v-3", message: "dlopen(libguile-srfi-srfi-1-
> v-3.a, 9): no suitable image found. Did find:
This problem is just another occurrence of the dlopen issue.
Neil
Index: libguile/stackchk.h
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/stackchk.h,v
retrieving revision 1.20.2.1
diff -u -r1.20.2.1 stackchk.h
--- libguile/stackchk.h 12 Feb 2006 13:42:51 -0000 1.20.2.1
+++ libguile/stackchk.h 10 Jan 2008 22:37:38 -0000
@@ -37,11 +37,11 @@
# if SCM_STACK_GROWS_UP
# define SCM_STACK_OVERFLOW_P(s)\
(SCM_STACK_PTR (s) \
- > (SCM_I_CURRENT_THREAD->base + SCM_STACK_LIMIT))
+ > (SCM_I_CURRENT_THREAD->base + ((SCM_STACK_LIMIT * sizeof(SCM)) / sizeof(SCM_STACKITEM)))
# else
# define SCM_STACK_OVERFLOW_P(s)\
(SCM_STACK_PTR (s) \
- < (SCM_I_CURRENT_THREAD->base - SCM_STACK_LIMIT))
+ < (SCM_I_CURRENT_THREAD->base - ((SCM_STACK_LIMIT * sizeof(SCM)) / sizeof(SCM_STACKITEM))))
# endif
# define SCM_CHECK_STACK\
{\
next prev parent reply other threads:[~2008-01-10 22:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-10 8:22 Mac PowerBookG4 OS X 10.4.11 (Tiger) guile test results Roger Mc Murtrie
2008-01-10 19:23 ` Neil Jerram
[not found] ` <41088A04-86D5-4351-B045-F084745A9B7F@IINET.NET.AU>
[not found] ` <873at52ujd.fsf@ossau.uklinux.net>
2008-01-10 22:28 ` Roger Mc Murtrie
2008-02-03 23:24 ` Neil Jerram
[not found] ` <EA79D2A8-EDBB-4D19-AE80-5962D562CB09@IINET.NET.AU>
2008-01-10 22:40 ` Neil Jerram [this message]
2008-01-10 23:10 ` Roger Mc Murtrie
2008-01-10 23:33 ` Roger Mc Murtrie
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=87y7ax1eze.fsf@ossau.uklinux.net \
--to=neil@ossau.uklinux.net \
--cc=ROGERMC@IINET.NET.AU \
--cc=bug-guile@gnu.org \
/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).