Bug 575383 - sftp dies on terminal resize
Summary: sftp dies on terminal resize
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libedit
Version: 13
Hardware: i686
OS: Linux
low
medium
Target Milestone: ---
Assignee: Kamil Dudka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-03-20 12:59 UTC by Edward Sheldrake
Modified: 2010-04-22 22:56 UTC (History)
2 users (show)

Fixed In Version: libedit-3.0-2.20090923cvs.fc13
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-04-22 22:56:30 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
my fix, seems to work for me (427 bytes, patch)
2010-03-20 12:59 UTC, Edward Sheldrake
no flags Details | Diff
revised patch (406 bytes, patch)
2010-03-23 12:48 UTC, Edward Sheldrake
kdudka: review+
Details | Diff

Description Edward Sheldrake 2010-03-20 12:59:00 UTC
Created attachment 401427 [details]
my fix, seems to work for me

Description of problem:
The "sftp" command is terminated if you resize the graphical terminal (xterm, gnome-terminal) it is running in, returning you to the shell.

The bug appears to be within libedit, because examples/fileman within the libedit source has the same problem.

Version-Release number of selected component (if applicable):
libedit-3.0-1.20090923cvs.fc13

How reproducible:
Always

Steps to Reproduce:
1. Start gnome-terminal
2. sftp 127.0.0.1
3. Resize the gnome-terminal, changing the number of rows or columns of text
  
Actual results:
sftp exits normally, returning you to the shell

Expected results:
sftp continues running

Additional info:
Fedora 12's libedit-2.11-4.20080712cvs.fc12 doesn't have this bug. There are significant changes in signal handling between the libedit versions, my fix seems to work, but is more of a workaround, it puts back the signal handlers, similar to existing code for SIGCONT.

Comment 1 Kamil Dudka 2010-03-22 19:34:39 UTC
(In reply to comment #0)
> Created an attachment (id=401427) [details]
> my fix, seems to work for me

Thank you for filling the bug and preparing the patch!

> Description of problem:
> The "sftp" command is terminated if you resize the graphical terminal (xterm,
> gnome-terminal) it is running in, returning you to the shell.

Confirmed. It's really annoying.

> The bug appears to be within libedit, because examples/fileman within the
> libedit source has the same problem.

Indeed. It works well again after libedit downgrade.

> Additional info:
> Fedora 12's libedit-2.11-4.20080712cvs.fc12 doesn't have this bug. There are
> significant changes in signal handling between the libedit versions, my fix

IMO this is the relevant one:

--- a/src/read.c
+++ b/src/read.c
@@ -172,7 +172,7 @@ read__fixio(int fd __attribute__((__unused__)), int e)
                return (e ? 0 : -1);
 
        case EINTR:
-               return (0);
+               return (-1);
 
        default:
                return (-1);

> seems to work, but is more of a workaround, it puts back the signal handlers,
> similar to existing code for SIGCONT.

It makes sense to me since SIGWINCH is the only signal which is not supposed to break the loop from all the 7 signals listed in src/sig.h. I'll propose the patch upstream, adding you to CC.

Comment 2 Edward Sheldrake 2010-03-23 12:48:42 UTC
Created attachment 402041 [details]
revised patch

Based on Kamil's comment #1, it has occurred to me that the call to sig_set() in the original patch is unnecessary (there's probably nothing wrong in all the changes to sig.c).

I tested the revised patch and it still works.

Comment 3 Kamil Dudka 2010-03-23 13:22:51 UTC
Comment on attachment 402041 [details]
revised patch

Looks good to me.

Comment 4 Edward Sheldrake 2010-03-23 16:16:02 UTC
After more thorough testing, the revised patch doesn't solve the problem completely. With the revised patch, although sftp doesn't exit after the first resize, it will still exit on a resize that follows a completed "put" command, even though you are back at the same "sftp>" prompt.

I have re-instated the original patch.

Comment 5 Kamil Dudka 2010-03-23 18:02:47 UTC
Good catch!  Thanks for the thorough testing.  Let's give some time to upstream folks now so that they look at the bug and the solution.

Comment 6 Kamil Dudka 2010-03-30 11:43:33 UTC
built as libedit-3.0-2.20090923cvs.fc14

http://koji.fedoraproject.org/koji/buildinfo?buildID=164510

The update for F-13 will follow.

Comment 7 Fedora Update System 2010-03-30 11:48:47 UTC
libedit-3.0-2.20090923cvs.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/libedit-3.0-2.20090923cvs.fc13

Comment 8 Fedora Update System 2010-04-01 19:30:48 UTC
libedit-3.0-2.20090923cvs.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update libedit'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/libedit-3.0-2.20090923cvs.fc13

Comment 9 Fedora Update System 2010-04-20 13:12:24 UTC
libedit-3.0-2.20090923cvs.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update libedit'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/libedit-3.0-2.20090923cvs.fc13

Comment 10 Fedora Update System 2010-04-22 22:56:22 UTC
libedit-3.0-2.20090923cvs.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.