Opened 10 years ago
Last modified 7 years ago
#1180 new defect
parley seems to insert the same sexpression to the reader again when getting input while sleeping
Reported by: | Christian Kellermann | Owned by: | Christian Kellermann |
---|---|---|---|
Priority: | major | Milestone: | someday |
Component: | extensions | Version: | 4.9.x |
Keywords: | parley input type ahead bug | Cc: | |
Estimated difficulty: |
Change History (2)
comment:1 Changed 7 years ago by
comment:2 Changed 7 years ago by
Should be addressed and fixed with commit 9a33e2b971a956ba710c3438b87c4db46b080b84
Note: See
TracTickets for help on using
tickets.
There are a few problems here:
parley
we get a non-falseprev-input
with the contents of the typeahead buffer in it so we have to process every element one by one before reading from the "real" prompt. Now, the(eof-object? (peek-char in)
condition doesn't make any sense because you want to processin
until an#!eof
occurs and then switch toreal-in-port
as soon as the typeahead buffer has been completely processed. The#<unspecified>
value you see in the trace comes from the other arm of theif
.object-copy
is dangerous, especially when thestate
record contains references toport
objects. With the adjustments outlined above I found that parley would crash the csi instance due to heap exhaustion while it was trying to copy such an object.(parley "")
gives an error, this is not really a problem but it could give a better error.