Strange behavior when returning from CTRL-Z - 5.24.0

[daniejstriata]

1. I pressed CTRL-Z to drop to shell. Using fg I went back to gdu. I pressed CTRL-Z to drop to shell again, then the following happened:
2. Just dropping to the shell with CTRL-Z and returning the gdu I can not use the arrows to scroll the tree.
   **
   
   **

Moving the mouse keeps appending to the shell:

This happened on Centos 7 inside bash.

[daniejstriata]

entered reset:

gdu did a rescan but terminal still was not happy.

[yurenchen000]

this situation seems to happen occasionally ?

• which OS, termianl application, TERM env do you using?

sometimes I have also encountered #249 (comment), in this broken state:

• another enter input is needed for shortkey apply effect
• mouse is broken
  //I think the terminal mode is corrupted

---

some research:

• tview.Application.Suspend seems not safe (when work with signal SIGTSTP?)

• handle screen state by screen.Fini and re-create new screen seems more safer (but it need lots of re-setup;
  gocui has a logic layer handle it and user don't have to , but tview seems lack of it )

[daniejstriata]

@yurenchen000 I can replicate it each time. I must just not touch the mouse then it should be fine.

I'm running Windows 11 with Windows Terminal 1.16 xterm-256color.

[yurenchen000]

@yurenchen000 I can replicate it each time. I must just not touch the mouse then it should be fine.

I'm running Windows 11 with Windows Terminal 1.16 xterm-256color.

sorry, I never test it on windows (and didn't expect it to work on windows).

I'm not sure is client or server problem, can you try it

• use different client
• OR different server
• OR try this tool (which use another screen suspend solution: finish old screen & create new one)
  Feat: add ctrl-z support wagoodman/dive#447

---

associate #249

[daniejstriata]

@yurenchen000 I tried the same in Putty and I do not experience this problem. It's happens only when I using Windows Terminal in my environment from my Windows 11 host.

[yurenchen000]

I try it on windows,
didn't encounter the same situation,
but encountered a similar one.

client \ server	ubuntu22 local	ubuntu22/20/18 via ssh	centos7 via ssh
ubuntu22 Terminator	Rare	Frequent	❌
win10 cmd	-	Frequent	❌
win10 powershell	-	Frequent	❌
win10 windows Terminal	-	Frequent	❌

Client:
win10: 22H2 (10.0.19045.2006)
windows terminal: 1.17.11461.0

A temporary workaround here:
// I haven't dig the deep (timing) reason yet
https://github.com/yurenchen000/gdu/tree/feat_ctrl_z_3

can you try if it solved the problem?
// it works on my tests

[daniejstriata]

@yurenchen000 I compiled your test branch. I was not able to trigger the problem using the dev binary anymore.

[daniejstriata]

I just noticed that Windows Terminal updated to 1.17 from last week, and now it is much harder to trigger the issue.

[yurenchen000]

I just noticed that Windows Terminal updated to 1.17 from last week, and now it is much harder to trigger the issue.

It seems that:

• terminal via ssh is easier to trigger than in local terminal
• open large folder is easier to trigger than small folder
• centos is easier to trigger than ubuntu
• after fg press ↑ quickly may easier to trigger

[daniejstriata]

I can confirm that after fg press ↑ quickly may easier to trigger

[yurenchen000]

I can confirm that after fg press ↑ quickly may easier to trigger

and,
did the workaround avoid it?

[daniejstriata]

Not avoid. Just harder to trigger.

[yurenchen000]

Not avoid. Just harder to trigger.

I didn't trigger again after this temp patch:

A temporary workaround here: // I haven't dig the deep (timing) reason yet https://github.com/yurenchen000/gdu/tree/feat_ctrl_z_3

can you explain how to trigger it (and the environment) ?

maybe sleep 1 sec is long enough for signal dispatch
(sleep still elapses after program suspend/stopped)

[yurenchen000]

I think it's about race condition of

• kill (it's async
• terminal resume

(so sleep can improve the situation
(I'll try a better way..