Re: Segmentation fault

Re: Segmentation fault

[frank schwidom]

-------- Original-Nachricht --------
Datum: Wed, 10 Oct 2007 18:27:42 +0200
Von: "frank schwidom" <schwidom@gmx.net>
An: bug-guile@gnu.org
Betreff: Segmentation fault

Hi

the following code leads to an segmentation fault in guile-1.6 and guile-1.8, when executed with --debug

currently the shortest Variant:
----------------
(let ((f (lambda (g) (delay (g)))))
  (force (f error)))
----------------

A discussion appeared already in http://paste.lisp.org/display/48972
(only for interest)

So long
Frank Schwidom


-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: Segmentation fault

[Neil Jerram]

"frank schwidom" <schwidom@gmx.net> writes:

> -------- Original-Nachricht --------
> Datum: Wed, 10 Oct 2007 18:27:42 +0200
> Von: "frank schwidom" <schwidom@gmx.net>
> An: bug-guile@gnu.org
> Betreff: Segmentation fault
>
> Hi
>
> the following code leads to an segmentation fault in guile-1.6 and guile-1.8, when executed with --debug
>
> currently the shortest Variant:
> ----------------
> (let ((f (lambda (g) (delay (g)))))
>   (force (f error)))
> ----------------

(To avoid anyone else duplicating the work:) I've started debugging
this.

     Neil



_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: Segmentation fault

[Neil Jerram]

"frank schwidom" <schwidom@gmx.net> writes:

> -------- Original-Nachricht --------
> Datum: Wed, 10 Oct 2007 18:27:42 +0200
> Von: "frank schwidom" <schwidom@gmx.net>
> An: bug-guile@gnu.org
> Betreff: Segmentation fault
>
> Hi
>
> the following code leads to an segmentation fault in guile-1.6 and guile-1.8, when executed with --debug
>
> currently the shortest Variant:
> ----------------
> (let ((f (lambda (g) (delay (g)))))
>   (force (f error)))
> ----------------

I believe the patch below is the correct fix for this.  Please test
and/or comment!

Regards,
        Neil

Index: libguile/ChangeLog
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/ChangeLog,v
retrieving revision 1.2412
diff -u -r1.2412 ChangeLog
--- libguile/ChangeLog	17 Oct 2007 21:56:09 -0000	1.2412
+++ libguile/ChangeLog	18 Oct 2007 23:26:19 -0000
@@ -1,3 +1,9 @@
+2007-10-19  Neil Jerram  <neil@ossau.uklinux.net>
+
+	* eval.c (unmemoize_delay): Extend the environment before
+	unmemoizing the promise thunk.  This fixes a segmentation fault
+	reported by Frank Schwidom.
+
 2007-10-17  Ludovic Courtès  <ludo@gnu.org>
 
 	* read.c (CHAR_IS_BLANK_): Add `\r' (ASCII 0x0d).  This fixes a
Index: libguile/eval.c
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/eval.c,v
retrieving revision 1.418
diff -u -r1.418 eval.c
--- libguile/eval.c	29 Jul 2007 15:16:46 -0000	1.418
+++ libguile/eval.c	18 Oct 2007 23:26:23 -0000
@@ -1268,7 +1268,13 @@
 unmemoize_delay (const SCM expr, const SCM env)
 {
   const SCM thunk_expr = SCM_CADDR (expr);
-  return scm_list_2 (scm_sym_delay, unmemoize_expression (thunk_expr, env));
+  /* A promise is implemented as a closure, and when applying a
+     closure the evaluator adds a new frame to the environment - even
+     though, in the case of a promise, the added frame is always
+     empty.  We need to extend the environment here in the same way,
+     so that any ILOCs in thunk_expr can be unmemoized correctly. */
+  const SCM new_env = SCM_EXTEND_ENV (SCM_EOL, SCM_EOL, env);
+  return scm_list_2 (scm_sym_delay, unmemoize_expression (thunk_expr, new_env));
 }
 
 
Index: test-suite/ChangeLog
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/test-suite/ChangeLog,v
retrieving revision 1.407
diff -u -r1.407 ChangeLog
--- test-suite/ChangeLog	17 Oct 2007 21:56:10 -0000	1.407
+++ test-suite/ChangeLog	18 Oct 2007 23:26:32 -0000
@@ -1,3 +1,10 @@
+2007-10-19  Neil Jerram  <neil@ossau.uklinux.net>
+
+	* standalone/test-use-srfi: Use -q to avoid picking up the user's
+	~/.guile file.
+
+	* tests/eval.test (promises)[unmemoizing a promise]: New test.
+
 2007-10-17  Ludovic Courtès  <ludo@gnu.org>
 
 	* tests/reader.test (reading)[CR recognized as a token
Index: test-suite/standalone/test-use-srfi
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/test-suite/standalone/test-use-srfi,v
retrieving revision 1.2
diff -u -r1.2 test-use-srfi
--- test-suite/standalone/test-use-srfi	15 Jan 2007 23:48:21 -0000	1.2
+++ test-suite/standalone/test-use-srfi	18 Oct 2007 23:26:32 -0000
@@ -19,14 +19,14 @@
 
 # Test that two srfi numbers on the command line work.
 #
-guile --use-srfi=1,10 >/dev/null <<EOF
+guile -q --use-srfi=1,10 >/dev/null <<EOF
 (if (and (defined? 'partition)
          (defined? 'define-reader-ctor))
     (exit 0)   ;; good
     (exit 1))  ;; bad
 EOF
 if test $? = 0; then :; else
-  echo "guile --user-srfi=1,10 fails to run"
+  echo "guile --use-srfi=1,10 fails to run"
   exit 1
 fi
 
@@ -38,7 +38,7 @@
 # `top-repl' the core bindings got ahead of anything --use-srfi gave.
 #
 
-guile --use-srfi=1 >/dev/null <<EOF
+guile -q --use-srfi=1 >/dev/null <<EOF
 (catch #t
   (lambda ()
     (iota 2 3 4))
@@ -47,7 +47,7 @@
 (exit 0)       ;; good
 EOF
 if test $? = 0; then :; else
-  echo "guile --user-srfi=1 doesn't give SRFI-1 iota"
+  echo "guile --use-srfi=1 doesn't give SRFI-1 iota"
   exit 1
 fi
 
@@ -56,12 +56,12 @@
 # exercises duplicates handling in `top-repl' versus `use-srfis' (in
 # boot-9.scm).
 #
-guile --use-srfi=17 >/dev/null <<EOF
+guile -q --use-srfi=17 >/dev/null <<EOF
 (if (procedure-with-setter? car)
     (exit 0)   ;; good
     (exit 1))  ;; bad
 EOF
 if test $? = 0; then :; else
-  echo "guile --user-srfi=17 doesn't give SRFI-17 car"
+  echo "guile --use-srfi=17 doesn't give SRFI-17 car"
   exit 1
 fi
Index: test-suite/tests/eval.test
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/test-suite/tests/eval.test,v
retrieving revision 1.19
diff -u -r1.19 eval.test
--- test-suite/tests/eval.test	19 Jan 2007 08:53:33 -0000	1.19
+++ test-suite/tests/eval.test	18 Oct 2007 23:26:32 -0000
@@ -294,7 +294,26 @@
 
     (pass-if-exception "implicit forcing is not supported"
       exception:wrong-type-arg
-      (+ (delay (* 3 7)) 13))))
+      (+ (delay (* 3 7)) 13))
+
+    ;; Tests that require the debugging evaluator...
+    (let ((dopts (debug-options)))
+      (debug-enable 'debug)
+
+      (pass-if "unmemoizing a promise"
+        (display-backtrace
+	 (let ((stack #f))
+	   (false-if-exception (lazy-catch #t
+					   (lambda ()
+					     (let ((f (lambda (g) (delay (g)))))
+					       (force (f error))))
+					   (lambda _
+					     (set! stack (make-stack #t)))))
+	   stack)
+	 (current-error-port))
+	#t)
+
+      (debug-options dopts))))
 
 ;;;
 ;;; letrec init evaluation



_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: Segmentation fault

[Ludovic Courtès]

Hi,

Neil Jerram <neil@ossau.uklinux.net> writes:

> I believe the patch below is the correct fix for this.  Please test
> and/or comment!

Works like a charm!

> +2007-10-19  Neil Jerram  <neil@ossau.uklinux.net>
> +
> +	* standalone/test-use-srfi: Use -q to avoid picking up the user's
> +	~/.guile file.

Thanks for taking care of this one too!

(I had forgotten about it, which may be an indication that we should
really start using the bug tracker.)

> +    ;; Tests that require the debugging evaluator...
> +    (let ((dopts (debug-options)))
> +      (debug-enable 'debug)
> +
> +      (pass-if "unmemoizing a promise"
> +        (display-backtrace

Could we hide the backtrace, because it's always a bit scary to see a
backtrace in the middle of the "PASS" lines?  Something like:

  (with-output-to-port (%make-void-port "w")
    (lambda ()
      ...
      (display-backtrace)

Alternatively, could `unmemoize-expr' somehow be used for the test?

Perhaps the `debug-enable' and `debug-disable' could be in a
`dynamic-wind', but that's not big deal.

Thanks,
Ludovic.


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: Segmentation fault

[Neil Jerram]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> Hi,
>
> Neil Jerram <neil@ossau.uklinux.net> writes:
>
>> I believe the patch below is the correct fix for this.  Please test
>> and/or comment!
>
> Works like a charm!

Thanks for trying it.

>> +2007-10-19  Neil Jerram  <neil@ossau.uklinux.net>
>> +
>> +	* standalone/test-use-srfi: Use -q to avoid picking up the user's
>> +	~/.guile file.
>
> Thanks for taking care of this one too!

I repro'd Frank's problem by adding the force/error expression to my
.guile.  Then, after fixing that, I ran make check, and just couldn't
understand (for a while) which test-use-srfi started failing... :-)

> (I had forgotten about it, which may be an indication that we should
> really start using the bug tracker.)

What would that involve?

> Could we hide the backtrace, because it's always a bit scary to see a
> backtrace in the middle of the "PASS" lines?  Something like:
>
>   (with-output-to-port (%make-void-port "w")
>     (lambda ()
>       ...
>       (display-backtrace)

Yes, I meant to do that but forgot.  No need for with-output-to-port
though; just need to change the second arg of display-backtrace to
(%make-void-port "w").

> Alternatively, could `unmemoize-expr' somehow be used for the test?

I looked at that, but couldn't work out what unmemoize-expr's args
should be.  Also, this would make the test depart further from the
reported scenario.  So I think best to stick with using
display-backtrace.

> Perhaps the `debug-enable' and `debug-disable' could be in a
> `dynamic-wind', but that's not big deal.

Yes, I'll do that.  There's a couple of places in the tests that use
debug-enable/disable like this, so it's worth adding a
with-debugging-evaluator form to (test-suite lib).

> Thanks,
> Ludovic.

Regards,
        Neil



_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: Segmentation fault

[Ludovic Courtès]

Hi Neil,

Neil Jerram <neil@ossau.uklinux.net> writes:

> ludovic.courtes@laas.fr (Ludovic Courtès) writes:

>> (I had forgotten about it, which may be an indication that we should
>> really start using the bug tracker.)
>
> What would that involve?

Not much actually.  Just mention it in the relevant pieces of
documentation.  The bug tracker automatically sends emails to
`bug-guile' when new bugs are reported or when the status of existing
bugs changes.  We can also assign a bug to a specific developer, which
can help coordinate efforts.

> Yes, I meant to do that but forgot.  No need for with-output-to-port
> though; just need to change the second arg of display-backtrace to
> (%make-void-port "w").

Right.

> I looked at that, but couldn't work out what unmemoize-expr's args
> should be.  Also, this would make the test depart further from the
> reported scenario.  So I think best to stick with using
> display-backtrace.

OK.

> Yes, I'll do that.  There's a couple of places in the tests that use
> debug-enable/disable like this, so it's worth adding a
> with-debugging-evaluator form to (test-suite lib).

Yes, makes sense.

Can you also add a `NEWS' entry?

Thanks,
Ludovic.



_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: Segmentation fault

[Neil Jerram]

ludo@gnu.org (Ludovic Courtès) writes:

>>> (I had forgotten about it, which may be an indication that we should
>>> really start using the bug tracker.)
>>
>> What would that involve?
>
> Not much actually.  Just mention it in the relevant pieces of
> documentation.  The bug tracker automatically sends emails to
> `bug-guile' when new bugs are reported or when the status of existing
> bugs changes.  We can also assign a bug to a specific developer, which
> can help coordinate efforts.

So would then ask people to raise bugs on savannah, instead of
emailing bug-guile?  Or can we implement something to catch emails to
bug-guile and automatically raise corresponding bugs on savannah?
(Surely someone has done that already?)

> Can you also add a `NEWS' entry?

Yes.  Everything related to this fix is now done, in 1.6, 1.8 and
HEAD.

     Neil



_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: Segmentation fault

[Ludovic Courtès]

Hi,

Neil Jerram <neil@ossau.uklinux.net> writes:

> So would then ask people to raise bugs on savannah, instead of
> emailing bug-guile?  Or can we implement something to catch emails to
> bug-guile and automatically raise corresponding bugs on savannah?
> (Surely someone has done that already?)

The former.  I'm not sure the latter is easily feasible.

Actually, some people already used the bug tracker to report bugs, but
most don't.

Thanks,
Ludovic.



_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: Segmentation fault

[Neil Jerram]

ludo@gnu.org (Ludovic Courtès) writes:

> Hi,
>
> Neil Jerram <neil@ossau.uklinux.net> writes:
>
>> So would then ask people to raise bugs on savannah, instead of
>> emailing bug-guile?  Or can we implement something to catch emails to
>> bug-guile and automatically raise corresponding bugs on savannah?
>> (Surely someone has done that already?)
>
> The former.  I'm not sure the latter is easily feasible.

It would be convenient if it worked though, as then we wouldn't have
to invalidate "email bug-guile@gnu.org" as a method of reporting bugs.

I feel like having a go at this; I'll report back on how it goes.

> Actually, some people already used the bug tracker to report bugs, but
> most don't.

Yes.  Ideally both methods would work and would have the same results.

Regards,
        Neil



_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: Segmentation fault

[Ludovic Courtès]

Hi Neil,

Neil Jerram <neil@ossau.uklinux.net> writes:

> It would be convenient if it worked though, as then we wouldn't have
> to invalidate "email bug-guile@gnu.org" as a method of reporting bugs.

Note: just because we recommend using the bug tracker doesn't mean we
should ignore messages sent manually to `bug-guile'!  :-)

> I feel like having a go at this; I'll report back on how it goes.

Nice!

Thanks,
Ludovic.


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: Segmentation fault

[Neil Jerram]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> Hi Neil,
>
> Neil Jerram <neil@ossau.uklinux.net> writes:
>
>> It would be convenient if it worked though, as then we wouldn't have
>> to invalidate "email bug-guile@gnu.org" as a method of reporting bugs.
>
> Note: just because we recommend using the bug tracker doesn't mean we
> should ignore messages sent manually to `bug-guile'!  :-)

No, of course not!

    Neil



_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: Segmentation fault

[Neil Jerram]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> Hi,
>
> Neil Jerram <neil@ossau.uklinux.net> writes:
>
>> I believe the patch below is the correct fix for this.  Please test
>> and/or comment!
>
> Works like a charm!

For 1.6 the fix is slightly different; please see below and let me
know if you have any comments.

To test this in 1.6, I've added all the "promises" tests from the HEAD
eval.test to the 1.6 eval.test.  All the tests pass for me, but is
there any risk that they might not pass on another platform, and so
introduce a regression in 1.6.x?

(I've committed the 1.6 fix and new tests for now, and will change them
if needed.)

Regards,
        Neil

Index: libguile/ChangeLog
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/ChangeLog,v
retrieving revision 1.1465.2.222
diff -u -r1.1465.2.222 ChangeLog
--- libguile/ChangeLog	4 Dec 2006 23:57:05 -0000	1.1465.2.222
+++ libguile/ChangeLog	20 Oct 2007 10:08:14 -0000
@@ -1,3 +1,9 @@
+2007-10-20  Neil Jerram  <neil@ossau.uklinux.net>
+
+	* eval.c (unmemocopy): For SCM_IM_DELAY, extend the environment
+	before unmemoizing the promise thunk.  This fixes a segmentation
+	fault reported by Frank Schwidom.
+
 2006-12-05  Kevin Ryde  <user42@zip.com.au>
 
 	* numbers.c (scm_product): For flonum*inum and complex*inum, return
Index: libguile/eval.c
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/eval.c,v
retrieving revision 1.234.2.12
diff -u -r1.234.2.12 eval.c
--- libguile/eval.c	2 Oct 2006 20:22:49 -0000	1.234.2.12
+++ libguile/eval.c	20 Oct 2007 10:08:18 -0000
@@ -1438,6 +1439,13 @@
 	case (SCM_ISYMNUM (SCM_IM_DELAY)):
 	  ls = z = scm_cons (scm_sym_delay, SCM_UNSPECIFIED);
 	  x = SCM_CDR (x);
+	  /* A promise is implemented as a closure, and when applying
+	     a closure the evaluator adds a new frame to the
+	     environment - even though, in the case of a promise, the
+	     added frame is always empty.  We need to extend the
+	     environment here in the same way, so that any ILOCs in
+	     thunk_expr can be unmemoized correctly. */
+	  env = EXTEND_ENV (SCM_EOL, SCM_EOL, env);
 	  goto loop;
 	case (SCM_ISYMNUM (SCM_IM_CALL_WITH_VALUES)):
 	  ls = z = scm_cons (scm_sym_at_call_with_values, SCM_UNSPECIFIED);
Index: test-suite/ChangeLog
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/test-suite/ChangeLog,v
retrieving revision 1.88.2.96
diff -u -r1.88.2.96 ChangeLog
--- test-suite/ChangeLog	4 Oct 2006 22:21:56 -0000	1.88.2.96
+++ test-suite/ChangeLog	20 Oct 2007 10:08:24 -0000
@@ -1,3 +1,11 @@
+2007-10-19  Neil Jerram  <neil@ossau.uklinux.net>
+
+	* tests/eval.test ("continuations"): Use with-debugging-evaluator.
+	("promises"): Add promise tests from CVS HEAD.
+
+	* lib.scm (with-debugging-evaluator*, with-debugging-evaluator):
+	New utilities.
+
 2006-10-05  Kevin Ryde  <user42@zip.com.au>
 
 	* tests/ftw.test: New file.
Index: test-suite/lib.scm
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/test-suite/lib.scm,v
retrieving revision 1.17.4.4
diff -u -r1.17.4.4 lib.scm
--- test-suite/lib.scm	23 May 2005 20:15:35 -0000	1.17.4.4
+++ test-suite/lib.scm	20 Oct 2007 10:08:24 -0000
@@ -33,6 +33,9 @@
  ;; Naming groups of tests in a regular fashion.
  with-test-prefix with-test-prefix* current-test-prefix
 
+ ;; Using the debugging evaluator.
+ with-debugging-evaluator with-debugging-evaluator*
+
  ;; Reporting results in various ways.
  register-reporter unregister-reporter reporter-registered?
  make-count-reporter print-counts
@@ -352,6 +355,22 @@
 (defmacro with-test-prefix (prefix . body)
   `(with-test-prefix* ,prefix (lambda () ,@body)))
 
+;;; Call THUNK using the debugging evaluator.
+(define (with-debugging-evaluator* thunk)
+  (let ((dopts #f))
+    (dynamic-wind
+	(lambda ()
+	  (set! dopts (debug-options))
+	  (debug-enable 'debug))
+	thunk
+	(lambda ()
+	  (debug-options dopts)))))
+
+;;; Evaluate BODY... using the debugging evaluator.
+(define-macro (with-debugging-evaluator . body)
+  `(with-debugging-evaluator* (lambda () ,@body)))
+
+
 \f
 ;;;; REPORTERS
 ;;;;
cvs diff: Diffing test-suite/tests
Index: test-suite/tests/eval.test
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/test-suite/tests/eval.test,v
retrieving revision 1.6.2.5
diff -u -r1.6.2.5 eval.test
--- test-suite/tests/eval.test	2 Oct 2006 20:12:44 -0000	1.6.2.5
+++ test-suite/tests/eval.test	20 Oct 2007 10:08:24 -0000
@@ -209,8 +209,7 @@
 
   (with-test-prefix "stacks/debugging"
 
-    (let ((dopts (debug-options)))
-      (debug-enable 'debug)
+    (with-debugging-evaluator
 
       (pass-if "make-stack"
         (stack? (call-with-current-continuation make-stack)))
@@ -220,10 +219,91 @@
 	  (or (boolean? id) (symbol? id))))
 
       (pass-if "last-stack-frame"
-        (pair? (call-with-current-continuation last-stack-frame)))
-
-      (debug-options dopts))
+        (pair? (call-with-current-continuation last-stack-frame))))
 
     ))
 
+;;;
+;;; promises
+;;;
+
+(with-test-prefix "promises"
+
+  (with-test-prefix "basic promise behaviour"
+
+    (pass-if "delay gives a promise"
+      (promise? (delay 1)))
+
+    (pass-if "force evaluates a promise"
+      (eqv? (force (delay (+ 1 2))) 3))
+
+    (pass-if "a forced promise is a promise"
+      (let ((p (delay (+ 1 2))))
+	(force p)
+	(promise? p)))
+
+    (pass-if "forcing a forced promise works"
+      (let ((p (delay (+ 1 2))))
+	(force p)
+	(eqv? (force p) 3)))
+
+    (pass-if "a promise is evaluated once"
+      (let* ((x 1)
+	     (p (delay (+ x 1))))
+	(force p)
+	(set! x (+ x 1))
+	(eqv? (force p) 2)))
+
+    (pass-if "a promise may call itself"
+      (define p
+	(let ((x 0))
+	  (delay 
+	    (begin 
+	      (set! x (+ x 1))
+	      (if (> x 1) x (force p))))))
+      (eqv? (force p) 2))
+
+    (pass-if "a promise carries its environment"
+      (let* ((x 1) (p #f))
+	(let* ((x 2))
+	  (set! p (delay (+ x 1))))
+	(eqv? (force p) 3)))
+
+    (pass-if "a forced promise does not reference its environment"
+      (let* ((g (make-guardian))
+	     (p #f))
+	(let* ((x (cons #f #f)))
+	  (g x)
+	  (set! p (delay (car x))))
+	(force p)
+	(gc)
+	(if (not (equal? (g) (cons #f #f)))
+	    (throw 'unresolved)
+	    #t))))
+
+  (with-test-prefix "extended promise behaviour"
+
+    (pass-if-exception "forcing a non-promise object is not supported"
+      exception:wrong-type-arg
+      (force 1))
+
+    (pass-if-exception "implicit forcing is not supported"
+      exception:wrong-type-arg
+      (+ (delay (* 3 7)) 13))
+
+    ;; Tests that require the debugging evaluator...
+    (with-debugging-evaluator
+
+      (pass-if "unmemoizing a promise"
+        (display-backtrace
+	 (let ((stack #f))
+	   (false-if-exception (lazy-catch #t
+					   (lambda ()
+					     (let ((f (lambda (g) (delay (g)))))
+					       (force (f error))))
+					   (lambda _
+					     (set! stack (make-stack #t)))))
+	   stack)
+	 (%make-void-port "w"))
+	#t))))
 ;;; eval.test ends here



_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: Segmentation fault

[Ludovic Courtès]

Hi,

Neil Jerram <neil@ossau.uklinux.net> writes:

> For 1.6 the fix is slightly different; please see below and let me
> know if you have any comments.

It seems unlikely to introduce a regression.  However, that means we
should keep producing bug-fix releases of 1.6?

Thanks,
Ludovic.



_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: Segmentation fault

[Neil Jerram]

ludo@gnu.org (Ludovic Courtès) writes:

> It seems unlikely to introduce a regression.  However, that means we
> should keep producing bug-fix releases of 1.6?

I suggest that we ask on the lists if there is any demand for another
1.6.x.  When we do this, we should say what has been fixed since 1.6.8
- which is very easy, because it's all in the NEWS file.

      Neil



_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Segmentation Fault

[Nigel Warner]

Hi all,

With gcc (Ubuntu 4.3.3-5ubuntu4) 4.3.3 and 1.9.15

(define (test-proc)
 (display "some text"))

(procedure test-proc)

produces a segfault. I forgot the ? on the end of procedure?
which is how I found this out.

Regards,

Nigel Warner

Re: Segmentation Fault

[Andy Wingo]

On Mon 07 Feb 2011 13:26, Nigel Warner <nwarner84@gmail.com> writes:

> (define (test-proc)
>  (display "some text"))
>
> (procedure test-proc)
>
> produces a segfault.

Good catch, thanks!  Fixed in git.

Andy
-- 
http://wingolog.org/

Segmentation fault

[frank schwidom]

Hi

the following code leads to an segmentation fault in guile-1.6 and guile-1.8, when executed with --debug

----------------
(define (println x) (display x) (newline))

(let ((y (lambda (f)
           ((lambda (g) (g g))
            (lambda (g) (f (lambda (x) ((g g) x)))))))
      (streamof
        (lambda (f) (lambda (x) (cons x (delay (f x)))))))
  (force (cdr ((y streamof) 1)))  ;; without this line a correct errormessage will arise; actually a segfault happens

  (println 1 2)) ;; error expexted, but segfault arises

----------------

A discussion appeared already in http://paste.lisp.org/display/48972
(only for interest)

So long
Frank Schwidom
-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile