#276 Problems with Gray streams causing stack overflow and segfau
Hello,
I'm having some strange problems using Gray
streams on version 2.35 (I did not have these problems
on version 2.33, I did not tested it on version 2.34).
Basically I use Gray stream to interweave calling of a
function when the system waits on input. To simulate
the problem, start clisp and load the attached source
file (clisperror.lisp), call then (enable-listeners),
and then type in the following
(let ((som 0))
(dotimes (tel 5 som)
(setf som (+ 1 tel som))))
(The newlines are important, I don't have a problem
when there is only one new line in the expression). I
get then the following
[3]> (let ((som 0))
(dotimes (tel 5 som)
(setf som (+ 1 te
*** - Lisp stack overflow. RESET
[4]>
*** - EVAL: variable DOTIMES has no value
The following restarts are available:
USE-VALUE :R1 You may input a value to be
used instead of DOTIMES.
STORE-VALUE :R2 You may input a new value for
DOTIMES.l
ABORT :R3 ABORT
Break 1 [5]>
In some cases I had a message about a undefined TEL and
then a segfault.
Is there something changed in Gray streams, so that the
assumption I made in 2.33 (where everything worked) is
not true anymore or is this a new bug.
PS. This problem is causing Jabberwocky my Lisp IDE to
fail in communication with a CLISP session.
Thanks in advance for any help
Marc Mertens
Contains the definition of the Gray stream and test code
Logged In: YES
user_id=5735
what I see is usually related to unread-char errors.
indeed, you have no control over the original *standard-input*,
so you cannot just pass unread-char to it -
it might have been read from between your read and unread.
Logged In: YES
user_id=5735
the attached code WFM.
please test and report back.
a listener implementation that works
Logged In: YES
user_id=5735
This bug report is now marked as "pending"/"works for me".
This means that we think that we cannot reproduce the problem
and cannot do anything about it.
Unless you - the reporter - act within 2 weeks,
the bug will be permanently closed.
Sorry about the inconvenience -
we hope your silence means that
you are no longer observing the problem either.
Logged In: YES
user_id=13143
Hello,
I tried the attached code (your remark on unread-char
makes sense to me), but unfourtenately I still have the
problem. Here are the exact steps I do to reproduce the problem:
1. Start clisp
2. Execute (load "listeners.lisp")
3. Execute (enable-listeners)
4. Type (let ((som 0)) followed by a return
5. Type (dotimes (tel 5 som) followed by a return
6. Type (setf som ( and I get a Lisp stack overflow
here is the full output of my Lisp session
[1]> (load "listeners.lisp")
;; Loading file listeners.lisp ...
;; Loaded file listeners.lisp
T
[2]> (enable-listeners)
#<LISTENER-INPUT-STREAM #x203A3ED6>
[3]> (let ((som 0))
(dotimes (tel 5 som)
(setf som (
*** - Lisp stack overflow. RESET
[4]>
Additionnal information:
1. (lispimplementation-version) gives
"2.35 (2005-08-29) (built 3336668514) (memory 3336668655)"
(as it works for you and worked in 2.33, could it be a
version related problem ?)
2. I tested it on a Linux 2.6.11.4 machine and compiled
clisp from the sources, but I originally detected the
problem because of a bug report sended to me about
Jabberwocky on windows, so I suspect it is a problem in
windows also.
3. When I type the whole let expression on one single line,
there is no problem.
Thanks for your help (and by the way for providing a
excellent Ansi Common Lisp)
Marc
Logged In: YES
user_id=5735
load listeners.lisp and evaluate
(let* ((s1 (make-string-input-stream "("))
(s2 (make-string-input-stream "())"))
(l (make-instance 'listener-input-stream :stream s2))
(c (make-concatenated-stream s1 l)))
(print (read c))
(close s1) (close s2) (close l) (close c))
to get segfault.
Logged In: YES
user_id=5735
thank you for your bug report.
the bug has been fixed in the CVS tree.
you can either wait for the next release (recommended)
or check out the current CVS tree (see http://clisp.cons.org\)
and build CLISP from the sources (be advised that between
releases the CVS tree is very unstable and may not even build
on your platform).