Tview stuck in infinite loop after shelling out.... #244
Comments
|
I just tried this myself but couldn't reproduce your problem. Could you send a short code snippet that illustrates this? |
|
@rivo thanks for looking into it and for tview!! I think there is a race in this code (link below) where we init the new screen after it's been set in the application when the app is suspended. I've moved the lock block after the init and this seem to be working now. This is hard to repro as I think the draw routine timing is a play here... Here is a ref: Line 189 in 3938f60 Thanks! |
|
@k8sland Do you mean you set |
|
Will reopen when there is more information. |
|
I'm experiencing this same issue. I am using Code snippet looks like this: And |
|
I have this issue before but I solved it by making sure there are no tview widgets methods being called when calling
also this workaround doesn't work |
|
I'm hitting this issue, and it's making my program useless because it locks up constantly. Here's a standalone reproducer: package main
import (
"os"
"os/exec"
"io/ioutil"
"github.com/gdamore/tcell"
"github.com/rivo/tview"
)
func main() {
app := tview.NewApplication()
box := tview.NewBox().
SetBorder(true).
SetTitle("Box Demo")
box.SetInputCapture(func (event *tcell.EventKey) *tcell.EventKey {
switch key := event.Key(); key {
case tcell.KeyRune:
switch event.Rune() {
// Hit `e` to spawn the editor
case 'e':
tmpfile, err := ioutil.TempFile("", "test.*.txt")
if err != nil {
panic(err)
}
path_tmpfile := tmpfile.Name()
tmpfile.Close()
app.Suspend(func () {
env_editor := os.Getenv("EDITOR")
path_editor, err := exec.LookPath(env_editor)
if err != nil {
panic(err)
}
cmd_editor := exec.Command(path_editor, path_tmpfile)
cmd_editor.Stdin = os.Stdin
cmd_editor.Stdout = os.Stdout
cmd_editor.Stderr = os.Stderr
if err := cmd_editor.Run(); err != nil {
panic(err)
}
})
// Without the following, it's much harder to reproduce the issue
if _, err := ioutil.ReadFile(path_tmpfile); err != nil {
panic(err)
}
os.Remove(path_tmpfile)
return nil
}
}
return event
})
if err := app.SetRoot(box, true).Run(); err != nil {
panic(err)
}
}When I Any ideas? |
|
@rivo Could we please re-open this, we have a reproducer and several reports of the issue occurring, it'd be nice to have a workaround — or even better, a hot fix. |
|
I tried this with your code and there was no deadlock. We're on Can you please let me know if this is still an issue? |
|
It looks like the issue went away with |
|
I didn't experience this. I tried it on macOS with iTerm2 and hitting e immediately sent me to my editor. What OS and terminal are you on? |
|
I'm using ArchLinux, the same issue is reproducible with Kitty ( |
|
I'm sorry but I don't have any way to test and debug it on these systems. Key events are produced by Line 267 in 09cec83 Then they are queued and picked up again here: Line 303 in 09cec83 You may want to check if this code gets executed when you press e. If the |
|
@lenormf - which version of tcell are you running? I think tcell v2.2.1 or later contains a fix for the first char being swallowed during suspend/resume operations... |
|
I'm using The first e is not swallowed up, I just have to hit another key for it to be executed. The other weird thing is if I double tap e, the editor spawns (first e). When I quit the editor, the program resumes. If I hit another key, the editor spawns again (second e, for the double tap). So it looks like keys are buffered, until the buffer hits a size of 2. The issue also occurs with different values of |
|
Well, for sure |
I had exactly the same issue with Arch Linux & termite. versions:
IMO the issue is related to gdamore/tcell#452, saying that
for the quick fix, I just downgraded tview to go get github.com/rivo/tview@7df0389
go get github.com/gdamore/tcell/v2@v2.2.0 |
|
tcell's issue 452 is fixed now... please retest. |
|
Echoing @gdamore here, please let us know if the problem still persists with the latest version. |
|
I am getting Code the same as in #244 (comment) except using Tried multiple shells and terminals. |
|
@dundee Could you please run the program listed here: gdamore/tcell#480 and let me know if this results in the same error? |
|
Yes, same error. I will paste details there. |
|
So, does this only happen on ArchLinux? I wonder if there is a bug in the terminal code there. The panic indicates a timeout reading from /dev/tty, but I don't think we actually attempt to read from that -- we issue a ioctls in the code path that has the panic, but not reads. Which version of ArchLinux are you using? I unfortunately don't have any experience with Arch, but I don't want to burn cycles trying to fix a problem only to find I can't reproduce it because I don't have the right version of Arch. |
|
I can confirm that the fix from gdamore/tcell#480 fixes this issue as well. |
|
Looks like some problem still persists on Windows. The test script in gdamore/tcell#480 works but tview application is not able to resume after being paused. It falls into deadlock: Not sure if it's worth the debugging though :) |
|
Minimal example: This example doesn't crash on the first suspend but on the second one: |
|
Interesting -- I tested this on Linux, but not Windows. I guess maybe there is a completely separate bug on Windows. One thing I did try is the mouse.go demo -- which goes through this several times. |
|
EDIT: Adding an Found this issue after hitting the same thing with a more/less identical chunk of code. Relevant snippet: editor := os.Getenv("EDITOR")
if editor == "" {
editor = "vi"
}
success := true
u.app.Suspend(func() {
cmd := exec.CommandContext(ctx, editor, f.Name())
cmd.Stdin = os.Stdin
cmd.Stdout = os.Stdout
cmd.Stderr = os.Stderr
if err := cmd.Run(); err != nil {
log.Printf("error while editing file: %v", err)
success = false
}
})The editor opens fine, but the program hangs after closing. I'm on Arch Linux, using alacritty + tmux, and using the latest versions of both tview ( |
@derailed granted i have no fucking clue how or what your app does, so in order to test i had to screw with the code to force open a json/task/whateverthing wezterm+tmux+vim+arch+go run+(running logseq api server start with a junk api key and zero data) go run ./... -api_key=bootybootybootybootybootybootybootybootybootybootybootybootybootybootyjust go running the latest git clone from your repo seems to work dandy. are you all good now?
func (u *UI) editTask(ctx context.Context, event *tcell.EventKey) *tcell.EventKey {
// NUKED ACTUAL TASK GETTING
// _, task, ok := u.currentTaskItem()
// if !ok {
// return event
// }
f, err := os.CreateTemp("", "logseq-tui-*.json")
if err != nil {
log.Printf("failed to create temp file for editing: %v", err)
return event
}
defer f.Close() // Best-effort
// NUKED PASSING UUID
orig, err := u.logseq.WriteBlockForEditing(ctx, "" , f)
if err != nil {
log.Printf("failed to load block for editing: %v", err)
return event
}
if err := f.Close(); err != nil {
log.Printf("failed to close temp file: %v", err)
return event
}
editor := os.Getenv("EDITOR")
if editor == "" {
editor = "vi"
}
success := true
u.app.Suspend(func() {
cmd := exec.CommandContext(ctx, editor, f.Name())
cmd.Stdin = os.Stdin
cmd.Stdout = os.Stdout
cmd.Stderr = os.Stderr
if err := cmd.Run(); err != nil {
log.Printf("error while editing file: %v", err)
success = false
}
})
if !success {
return event
}
u.app.Sync()
updatedF, err := os.Open(f.Name())
if err != nil {
log.Printf("failed to open file after editing: %v", err)
return event
}
defer updatedF.Close()
if err := u.logseq.ApplyDiffFromEditedBlock(ctx, orig, updatedF); err != nil {
log.Printf("failed to apply diff to edited block: %v", err)
return event
}
if err := u.refreshList(ctx); err != nil {
log.Printf("failed to refresh list after edit: %v", err)
return event
}
return nil
} |
I'm not the original poster, just someone who ran into the same behavior, but I was indeed able to fix the problem by adding an |
Hi,
First off thank you for this great project! I am having an issue in the latest code base while shelling out using Suspend. I issue a command and forward stdin, stdout, stderr. When the command completes tview is completely non responsive and the screen is partially drawn + cpu pegged. Ctrl-C has no effect. It seems I am stuck in a screen rendering loop somewhere. Any advise or things I could try out? Thanks! BTW this used to work fine a few month ago....
The text was updated successfully, but these errors were encountered: