On a mac: The cursor position could not be read within a normal duration about reedline HOT 33 CLOSED

Looks like we don't handle any failure in our demo. I've updated it here: 289188e

@mzanrosso / @stormasm - can you try again with the latest source? You'll still see an error if it happens, but hopefully it'll pick back up and give you a new prompt+input to work with.

from reedline.

@stormasm do you know roughly how long it takes? (like at least an hour?)

from reedline.

@jntrnr yes its a long time --- I believe way more than one hour but less than one day. I have all of these different reedline terminals up including now engine-q and nucli-reed so every once in awhile I see this message --- was wondering if anyone else has seen it ? I am running a Mac Catalina 10.15.6 --- not that it matters but just an FYI.

This specific message did come from engine-q
But I have seen it as well in the past coming from other reedline apps of mine.

from reedline.

Might be something we have to file with crossterm There seems to be another unrelated crash crossterm-rs/crossterm#367

The cursor position is retrieved in crossterm by flushing an Escape code to stdout and then polling for the event (with some kind of locking mechanism underneath) with a 2 sec timeout.

https://github.com/crossterm-rs/crossterm/blob/24d0f561e8b5501c18f8e7fd18a60be0624dad68/src/cursor/sys/unix.rs#L30-L54

If we don't leak some resources on the reedline side this might be a system pathology caught by crossterm.
Would you mind running a /usr/bin/time equivalent for Mac with the reedline app to maybe catch how long it takes to crash or how much peak memory was consumed?

from reedline.

@sholderbach thanks I will research further and report back to you when I have more info ---- it could be a weird bug in my code as I am doing some experimentation with engine-q...

from reedline.

No repro on Linux - let it run yesterday, slept the laptop, and woke it up. Neither was able to break. May be OS-specific

from reedline.

No repro on Linux - let it run yesterday, slept the laptop, and woke it up. Neither was able to break. May be OS-specific

I can confirm that even my MacOS 12 beta 3 is affected by this problem

from reedline.

I'm giving it a try on macOS here so see if I can repro. Would like to see if we can get this fixed before the release. Something I'm hoping to do fairly soon is to integrate reedline into nushell, but if we're having stability issues that's not going to work.

from reedline.

I also tried to provoke the issue under Linux in gnome-terminal using different starting conditions for the reedline demo app but was not able to catch an error.
I ran perf on an idling demo app prompt, and with the full_repaint triggered for the refreshing clock, the crossterm::cursor::position function (throwing the Error) is basically part of the hotpath.

from reedline.

But even trying to poll the cursor position every millisecond (changing the Event polling in reedline) doesn't trigger the Error for me (even though the terminal emulator process starts to consume some serious CPU). Crossterm does not specify any contract we have to uphold or mention any compatibility notes. We probably should bring this to their attention.

from reedline.

Seems like a good take-away here is that if we're animating, we're increasing the change of hitting a platform-specific issue. We may want to make the animating prompt something you can disable so that it's only drawn when necessary. That doesn't fix the issue, but it would decrease the chance of hitting it.

@sholderbach - yeah I'm feeling more convinced it's a macOS-specific issue. Still trying to find a repro

from reedline.

On our side we might consider if we get by with dropping the error and reusing a cached position or setting to a desired one explicitly and then retrying reading.

from reedline.

@sholderbach yeah I like that idea. at the very least, be a little more flexible if we do encounter errors.

If we get in a rare state where the position changes but we can't get it, the user should be able to hit enter and get back to a clean prompt

from reedline.

This one seems to be also happening with an ssh session into Linux (WSL) crossterm-rs/crossterm#367

from reedline.

Ok I grabbed the latest reedline and engine-q and will let them both run overnight...

from reedline.

Looks like we don't handle any failure in our demo. I've updated it here: 289188e

@mzanrosso / @stormasm - can you try again with the latest source? You'll still see an error if it happens, but hopefully it'll pick back up and give you a new prompt+input to work with.

I will try asap, now I'm a bit busy with other stuff here; but thanks for the commit!

from reedline.

Both engine-q and the reedline demo ran overnight and in the morning (of course) there is no error showing up on either one... So far, so good ---- will report here if / when I see something again.

from reedline.

bingo ! just reproduced the error after firing up terminal in less than 5 minutes...

Error: Custom { kind: Other, error: "The cursor position could not be read within a normal duration" }

so it crashed on my Mac in less than 5 minutes running engine-q

from reedline.

@stormasm - oh we should fix engine-q also. The fix I did was to the demo for reedline, and I'm betting engine-q needs the same fix. I'll take a look

from reedline.

@stormasm - just checked in a similar fix to engine-q that I used for reedline

from reedline.

@jntrnr ok sounds good ! I saw the fix you did to reedline, also you may want to put into the Cargo.toml file in engine-q to pull in the branch = main

reedline = {git = "https://github.com/jntrnr/reedline", branch = "main"}

from reedline.

and possibly a .gitignore file too...

from reedline.

ok cool ---- just saw your changes ---- thanks...

from reedline.

Caused by:
failed to load source for dependency reedline

Caused by:
Unable to update https://github.com/jntrnr/reedline

Caused by:
failed to find branch master

Caused by:
cannot locate remote-tracking branch 'origin/master'; class=Reference (4); code=NotFound (-3)

from reedline.

@stormasm - I wonder what is causing it. cargo update seems to run okay for me.

from reedline.

> rustc --version
rustc 1.54.0-nightly (ed597e7e1 2021-06-08)

I can switch to stable and see if I can repro

from reedline.

Yeah stable does it. @stormasm if you want to submit the branch PR, I can land it

from reedline.

@stormasm - went ahead and landed your fix

from reedline.

Any repros after the fixes landed?

from reedline.

so far I have not seen any issues, but I have been away for a few days and have not banged on it too much... I will hopefully be spending more time this week with engine-q / and that is where I saw the problem last --- will report back here if I can reproduce again this week...

from reedline.

@jntrnr so I am getting the same error message as above
only this time it does not crash engine-q.

Error: Custom { kind: Other, error: "The cursor position could not be read within a normal duration" }

This time engine-q did not crash (obviously thanks to your most recent fix)
--- time elapsed was about 13 hours...

from reedline.

@stormasm seems we're getting that as the same error. That error, I believe, is coming from crossterm since it's not coming from reedline.

We could try reporting it to them. Maybe they've seen it before?

from reedline.

All of these comments are about developing with engine-q on my Mac.

So I removed the timestamp from the prompt...
https://github.com/stormasm/reedline/tree/notime
And the problem I stated above still persists randomly at times...
So drawing the timestamp every second is not the issue.

Also I am seeing some strange behavior with the Command-K key sequence.
As well as strange behavior if my prompt is at the bottom of the screen.
Where as if it is at the top of screen / and I got there with a Ctrl L all is fine.

If I hit Ctrl L it clears the screen as it should.
But if I hit a bunch of returns till I get in the middle of the screen,
and then hit Command-K it clears the screen like it does in bash,
but then redraws the cursor in the exact same spot it was at before it clears the screen.

So reedline is clearing the screen and then repainting the cursor in the exact same spot.
Very similar behavior as to what I see when I println! in a loop in engine-q
But this only happens when I am at the bottom of the screen.

If I Ctrl-L to the top --- then I do not see any repaint at all of the println! stuff...

from reedline.