Hide Forgot
Description of problem: Version-Release number of selected component (if applicable): xterm-253-1.el6 How reproducible: Systematic Steps to Reproduce: 1.Start a gnome session or any X11 session 2.Start xterm using the xterm command in a shell 3. Actual results: -After typing a command and then pressing the "Enter" key it is often required to press the "Enter" key again to get the shell prompt back -When a key is pressed, it is often required to press another key to see the corresponding letter being displayed Expected results: The shell prompt comes back on its own after a command and the "Enter key" have been used. When a key is pressed, one can see the result on the display without any other action. Additional info: I tried an older version of xterm (from RHEL5), but no difference; it might be just a configuration issue but I can't find it. Shell used is /bin/bash I did try mksh as well.
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative.
Does this happen also in gnome-terminal or any other application? Do you have any X resources set for xterm? $ xrdb -query | grep xterm
(In reply to comment #3) > Does this happen also in gnome-terminal or any other application? No it does not happen in gnome-terminal or when switching to VT with ctrl+alt+fn. So far, I have only seen it with xterm. > Do you have any X resources set for xterm? > > $ xrdb -query | grep xterm This command does not return any output.
Two more things I have noticed: -The problem does not happen on virtual machines, only on physical PC -If I start the xterm using 'strace xterm' then the problem does not happen
I packaged latest upstream version of xterm (276) and using it seems to make the problem disappear.
Can you please try binary search to find out which upstream version fixed this?
(In reply to comment #7) > Can you please try binary search to find out which upstream version fixed this? Upstream version 257 fixes the issue.
Thomas, do you recall which change in the patch #257 could be related to this issue? Could it be the memory allocation problem?
no - the memory allocation problem seems to be related to select/paste. There's a remote chance that an application switched to UTF-8 mode and fell into one of the cases for the "ESC%G". But I don't see anything for #257 that seems to be related to keyboard processing, unless the user is pressing some key-modifier (as might be needed for a laptop).
(In reply to comment #10) > no - the memory allocation problem seems to be related to select/paste. > There's a remote chance that an application switched to UTF-8 mode > and fell into one of the cases for the "ESC%G". But I don't see anything > for #257 that seems to be related to keyboard processing, unless the user > is pressing some key-modifier (as might be needed for a laptop). I haven't used any laptop in my testing. Since the problem does not appear on Virtual Machines or when using "strace xterm", I was thinking maybe some keyboard events were lost and that slowing down the application made it work correctly; looking at the diff between 256 and 257 I haven't found a reason yet to sustain this claim; I keep investigating.
Or, as suggested, the memory allocation could be the problem. It's hard to say - but I do recall that isolating it was not simple, since the symptoms were obscure.
Created attachment 533771 [details] patch against 253 fixing the problem observed
Created attachment 533772 [details] Patch against 256 that fixes the problem observed Patch against 256 that fixes the problem observed
An addition about the problem I experience : - if a key is pressed and the key is not displayed or if the prompt does not come back after a command is issued, the key can be displayed or the prompt can return if one waits about 8 seconds or if another key is pressed. After further research, I narrowed the diff between 256 and 257 to the Scroll Lock feature. However, I do not understand what would cause/fix the problem by looking at this patch. Maybe you can shed some light on this ? Or is it some kind of side effect ?
will take a look (thanks)
Red Hat Enterprise Linux 6 transitioned to the Production 3 Phase on May 10, 2017. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available. The official life cycle policy can be reviewed here: http://redhat.com/rhel/lifecycle This issue does not appear to meet the inclusion criteria for the Production Phase 3 and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL: https://access.redhat.com