Opened 11 years ago
Last modified 8 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 8 years ago by
comment:2 Changed 8 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:
parleywe get a non-falseprev-inputwith 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 processinuntil an#!eofoccurs and then switch toreal-in-portas 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-copyis dangerous, especially when thestaterecord contains references toportobjects. 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.