posit-dev / positron

Positron, a next-generation data science IDE
https://positron.posit.co
Other
2.6k stars 79 forks source link

R: Hang when emitting a large amount of output #1447

Open jmcphers opened 1 year ago

jmcphers commented 1 year ago

Positron Version

Positron Version: 2023.09.0 (Universal) build 3772
Code - OSS Version: 1.82.0
Commit: 3dbeec7a2f13521c19ab89aacf0d0d8a5d3d3cbb
Date: 2023-09-28T03:09:11.112Z
Electron: 25.8.0
ElectronBuildId: undefined
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Darwin arm64 22.6.0

Repro Steps

Create an .R file with these contents:

for (x in 1:5000) print("kwljhlw ewqe wlejq wl jeqlw jeqlw jelqkwe jqwl jeql jeqlj elqkj eqlkwe jqlkj elqkwe jklqw ewqljwlqeqljekjqwlkjeqlwkejqlw")

Run the code with Cmd + Enter. Wait a beat, then run it again.

The R interpreter never leaves the Busy state after this, and interrupting it has no apparent effect (see also #1105).

https://github.com/posit-dev/positron/assets/470418/26dae243-f52b-4194-a00b-74e25f38cf65

(originally discovered by @softwarenerd)

jmcphers commented 1 year ago

You have to quit Positron to get out of this state. :-( We should really have a way to force quit (see https://github.com/posit-dev/positron/issues/1422)

DavisVaughan commented 1 year ago

I cannot reproduce 😞

jmcphers commented 1 year ago

I can't either!

jmcphers commented 1 year ago

@softwarenerd is still seeing this.

softwarenerd commented 1 year ago

This is definitely still a problem. It's is 100% reproducible for me.

If I execute:

for (x in 1:20000) {
    print(sprintf("This qlwe qlejql ejkqw ejqw eqwej qwelqjwe qwejq wis row %d", x))
}

The R language runtime will hang:

Image

DavisVaughan commented 1 year ago

I looked at this for a little while today - my notes so far are that it looks like the frontend isn't receiving the final idle state. AFAICT R is not actually crashing here.

If you look in the Runtime R output logs, you will see a 'status' (the idle) being sent at the end of the logs. It seems like it really is being sent over from the Rust side.

On the Typescript side, it seems like the idle status isn't coming through zmq, almost like it is being dropped...I tried setting breakpoints in our _iopub.onMessage() handler but never see the corresponding idle come through.

The many many 'stream' messages also all go through this one IOPub channel, so I wonder if they are somehow clogging it up enough to prevent the 'status' one from getting through, I'm not really sure.


Planning to discuss further with Lionel tomorrow