Opened 13 years ago
Last modified 3 years ago
#7997 new bug
Selecting a large range of text within terminal, then right-clicking on selected text locks up the terminal application.
| Reported by: | frankenburps | Owned by: | jackburton |
|---|---|---|---|
| Priority: | normal | Milestone: | R1 |
| Component: | Applications/Terminal | Version: | R1/alpha3 |
| Keywords: | gci2011 | Cc: | |
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
This happens to me consistently. Am running the release version of r1a3, running in VMware fusion 4.1.2 for macos x 10.6.8.
Attachments (1)
Change History (10)
by , 13 years ago
| Attachment: | crashedterminal.png added |
|---|
comment:1 by , 13 years ago
When I shut down haiku after this happens, I'm told the terminal "might be blocked on a modal panel". Have to kill it to shut down.
comment:2 by , 13 years ago
To reproduce this, for example, install tiltos. IN terminal, type box-repos -s to get a list of all packages. Select the full list of package names. Right-click in the hopes of getting a menu with the copy option. The terminal will crash.
comment:3 by , 13 years ago
| Component: | User Interface → Applications/Terminal |
|---|---|
| Owner: | changed from to |
Thanks for the report! When an application crashes, you should receive an error prompt with an option to debug the crashed application. If you don't receive the prompt, it would appear that Terminal locks up, either in a busy loop or in a dead-lock, rather than crashes.
comment:4 by , 13 years ago
| Summary: | Selecting a large range of text within terminal, then right-clicking to try to call up a menu crashes the terminal application. → Selecting a large range of text within terminal, then right-clicking on selected text locks up the terminal application. |
|---|
comment:5 by , 13 years ago
| Keywords: | gci2011 added |
|---|
The problem was checked during GCI 2011. It happens to me, on hrev43238, running on VirtualBox 4.1.4 (Debian Sid) and does exactly, as it says in description: If you select a large portion of text and then want to copy it, it freezes.
follow-up: 7 comment:6 by , 13 years ago
JFYI: That looks like the concurrency problem in our pty implementation:
a) Selecting the the text in terminal automatically copy the selection into the clipboard;
b) Pressing either middle or right button inserts current text from the clipboard into the Terminal;
c) Terminal writes all those strings at once - and it looks like the app is blocked because of some reasons the text doesn't displayed on the screen;
d) Anyway at some time the TermParse::PtyReader become "Bad file descriptor" error on the next attempt to read and is forced to exit with NotifyQuit() call.
From the other side: What sense to paste those thousands of lines into the Terminal? Note that they are interpreted as usual CLI commands and shell attempts to run them immediately and produce error messages. May be pasting should be blocked for any multilined contents?
follow-up: 8 comment:7 by , 13 years ago
Replying to siarzhuk:
From the other side: What sense to paste those thousands of lines into the Terminal? Note that they are interpreted as usual CLI commands and shell attempts to run them immediately and produce error messages. May be pasting should be blocked for any multilined contents?
That's a perfectly valid use case if your terminal currently contains, e.g. an open session of vim.
comment:8 by , 13 years ago
Replying to anevilyak:
Replying to siarzhuk:
From the other side: What sense to paste those thousands of lines into the Terminal? Note that they are interpreted as usual CLI commands and shell attempts to run them immediately and produce error messages. May be pasting should be blocked for any multilined contents?
That's a perfectly valid use case if your terminal currently contains, e.g. an open session of vim.
Yes, just have checked it under my "reference" FreeBSD xterm. ;-)
after selecting text in terminal and right-clicking within selected text to try to call up a menu to copy the text