Repeated errors (input_pushback not null) when reconnecting.

[Greg Nelson]

When reconnecting to a server after losing my internet connection, or after a timeout, I frequently receive the cryptic error message:

Error: input_pushback not null!

I am not sure what this error means, or what causes it, but retrying always makes it go away. It would be rather nice if the system would do at least one retry of the current operation when this error occurs, thus avoiding the need for both the error message and the manual retry.

[Daniel Beardsmore]

I find this strange as I see it within a LAN where FileZilla and the SSH server are on the same LAN segment (so there should be no NAT timeouts etc). Occurs completely randomly, so long as I've not touched FileZilla for a little while -- no idea how long, or whether there's a consistent period before failure.

If it happens when I'm switching directory (via synchronised browsing), I have to click somewhere I don't want to be so that it will realise its mistake and reconnect, and then click back on the directory I wanted to go to in the first place now that it's not highlighted in the tree.

It's more annoying if it happens when I go to upload something, as I have to poke it until it reconnects, otherwise I lose my place in the directory tree if I manually disconnect and reconnect. (Not sure if that gives me the same error, but it's the same problem.)

As gnelson points out, solved every time by a reconnect, so FileZilla could resolve this transparently by automatically reconnecting without having to be poked and prodded.

[Daniel Beardsmore]

Some additional details: FileZilla (currently 3.5.0) runs in Windows XP, and the host is OpenSSH_5.5p1 Debian-6, OpenSSL 0.9.8o 01 Jun 2010. FileZilla is on a PC with the stock Windows Firewall only.

The program never detects any timeout/disconnect, only that when you attempt to perform a task, you'll get log entries of the form:

17:22:23 Status: Retrieving directory listing...
17:22:23 Command: cd "/some/path/on/server"
17:22:23 Error: input_pushback not null!
17:22:23 Error: Failed to retrieve directory listing

You can't then click the path entry in the tree a second time, but if you click the corresponding path in the other tree (I've got synchronised browsing on), it will then automatically reconnect.

[Ben]

I have been experiencing this problem for over two years. I suspect that there are many others like me who couldn't be bothered to register and submit a comment, primarily because the issue seemed too pervasive for the FileZilla developers to ignore. Not so, apparently.

This occurs very reliably and predictably, so, if it's a server-side problem, I'm happy to provide whatever information is relevant.

The server-side setup is Ubuntu 10.04.4 LTS with pure-ftpd 1.0.24-1.

The problem occurs on every version of Windows that I've tried (XP through Windows 8) and with all recent versions of FileZilla (within the past two years), including the current version as of this writing, 3.6.0.2.

[Ben]

It's a miracle! This seems to have been fixed somewhere between 3.6.0.2 and 3.7.0.1. Almost all releases since 3.6.0.2 have included TLS-related fixes, so I'm not sure which release actually fixed the problem, but it seems to be resolved.

Can anyone else confirm, so that we can close-out this three-year-old ticket?

THANK YOU, to whomever fixed this most annoying bug, finally!

[Daniel Beardsmore]

I'll upgrade the program tomorrow and see ... I will have to leave it a few weeks to feel relatively confident that the issue is now gone.

[Daniel Beardsmore]

Same thing again now:

...
14:21:32 Status: File transfer successful, transferred 511 B in 1 second
14:40:43 Status: Retrieving directory listing...
14:40:43 Command: cd "/some/path/on/server"
14:40:43 Error: input_pushback not null!
14:40:43 Error: Failed to retrieve directory listing

Client is FileZilla 3.7.0.1 in Windows XP
Server is OpenSSH_5.5p1 Debian-6, OpenSSL 0.9.8o 01 Jun 2010 in Debian 6

No reconnect attempt was made.

[Ben]

It is possible that your operating system (Windows XP) is a factor in this problem? I'm on Windows 7 and the problem seems to be gone (at least in the context in which I experienced it). Windows XP comes-up short in other areas of TLS implementation, such as no ability to support SNI. Maybe this is a similar case.

The problem as I experienced it was that if I left FileZilla inactive long enough for the server to disconnect me automatically, and then I came back and hit "F5" to reload the remote directory view, I would see the "Error: input_pushback not null!" error.

Now, if I do the same thing, FileZilla re-establishes the connection correctly. For whatever it's worth, here's what I see when the remote server disconnects me due to timeout:

Response: 421 Timeout - try typing a little faster next time
Error: GnuTLS error -110: The TLS connection was non-properly terminated.
Status: Server did not properly shut down TLS connection
Error: Disconnected from server: ECONNABORTED - Connection aborted

I don't remember the error messages being so verbose previously. In particular, I don't remember seeing "GnuTLS error -110: The TLS connection was non-properly terminated", so, the developers definitely seem to have worked on this family of issues.

[Daniel Beardsmore]

I have no idea, but I figured I would at least provide the details. I will eventually switch to Windows 8 :)

[guaycuru]

I'm on Windows 7 x64 and can confirm that this Issue also happens with me, and have been happening for some years now!
Just leave Filezilla connected for some time (a long time probably) and then try to change folders on the remote side.

[Knocks]

Still happening to me on version 3.7.3. This is extremely annoying as I have to disconnect from the site and reconnect again instead of clicking on any folder and re-initiating the connection.

[Daniel Beardsmore]

It looks like this is being caused by fzsftp.exe terminating unexpectedly.

I have a problem where idle periods sometimes cause fzsftp.exe to hang after a random amount of elapsed time, so I've got used to opening Process Explorer and terminating it, and retrying the operation.

Twice now, when I've had "input_pushback not null!" instead of a hang, I've gone to kill fzsftp.exe, only to find that it had just terminated (the child process was missing the first time, and this time it was highlighted in red to show that the process had just terminated within the last three seconds). No sign of Dr Watson and no entry in the event log to suggest that Windows was made aware of the crash, so I presume that the program is undergoing a controlled exit, but that FileZilla is not expecting the process to exit, and is getting confused when the socket, handle or pipe into the SFTP process breaks.

(It should be possible to tell from the source code what the specific conditions are for this error message, though.)

[webformatik]

I recently changed all my Filezilla FTP configs to sftp and now i experience this annying issue very often.

After a not so long time of inactivity, i will get "input_pushback not null!" when trying to change folder - with delays, reconnect and so on.

But i never got it with file upload! Even after a long time of inactivity i'm still able to upload, as long as i stay in the same folder!

(Windows 7 x64, Filezilla 3.9.0.5)