Opened 15 years ago

Closed 15 years ago

Last modified 10 years ago

#4105 closed Bug report (fixed)

FileZilla crashes when connection to remote FZ server is broken

Reported by: Boulder Owned by: Tim Kosse
Priority: high Component: FileZilla Client
Keywords: crash connection server client Cc:
Component version: Operating system type: Windows
Operating system version: Vista SP1


A downloading FileZilla client crashes and loses the download queue on my friend's computer when I restart my computer which runs the FileZilla server application he is connected to. Last time the crash situation included an "Illegal operation" Windows error.

Attachments (1)

mah.log (43.3 KB ) - added by ilpipistrello 15 years ago.
log before crash

Download all attachments as: .zip

Change History (9)

comment:1 by Tim Kosse, 15 years ago

Status: newmoreinfo

Which version of FileZilla?

Which protocol are you using?

comment:2 by Boulder, 15 years ago

Status: moreinfonew

FZ client version 3.1.6, server version 0.9.27 beta. The issue can be avoided if I first take the server offline before restarting the computer.

The protocol is SSL/TLS. I've not tried non-encrypted protocols.

comment:3 by ilpipistrello, 15 years ago

just to report the same problem: client crash and lost queue. Queue is about 6000 files long. Client 3.2.2-rc1 on Vista SP1, I've been having the same problem on client since version 3.1. Connection is normal FTP.

comment:4 by Tim Kosse, 15 years ago

Status: newmoreinfo

Set debug level to 4 and enable logging to file. Make it crash. Then attach logfile here.

comment:5 by Boulder, 15 years ago

Strange..I cannot reproduce it now. Using the same server version as before and the client on another computer is v3.2.1. The log file says that the server closed the connection. The client was able to successfully restart the download as soon as I got the server computer up and running.

Perhaps ilpipistrello is able to reproduce the issue?

by ilpipistrello, 15 years ago

Attachment: mah.log added

log before crash

comment:6 by ilpipistrello, 15 years ago

Operating system version: XP SP3Vista SP1
Status: moreinfonew

I added the log as requested. I upgraded from version 3.2.1 to 3.2.2 (still Vista SP1); queued 9600+ files and started transferring. Most of them were skipped as already (previously) uploaded.
I had to cut part of the log as it exceeded the max limit size, but (I think) it's the non relevant part of skipping files.

I used Italian language in log, although FAQs required English, as it didn't crash with English language the several times I tried to have the server disconnected (and this fact seemed quite strange as Client always crashed before, when using Italian). As I switched back to Italian, it crashed again, and here's the log.
Right now I switched to English again, so in case it crashes I will attach the new report (in English). On the other hand, would it NOT crash again, I would think it language-related.

comment:7 by Tim Kosse, 15 years ago

Owner: set to Tim Kosse
Priority: normalhigh
Status: newaccepted

Funny thing, setting my own language to Italian and I could immediately reproduce it.

comment:8 by Tim Kosse, 15 years ago

Resolution: fixed
Status: acceptedclosed

Actually it has nothing to do with the language, was pure coincidence.

Deleting CFileZillaEnginePrivate::m_pControlSocket could reset CFileZillaEnginePrivate::m_pCurrentCommand during a connect command. Happens if a connection gets closed and before processing the close event, some command gets started, fails IsConnected() and returns FZ_REPLY_NOTCONNECTED and then executing a connect command. If that happens, CControlSocket::m_closed is not yet true, CFileZillaEnginePrivate::ResetOperation gets called and m_pCurrentCommand deleted while still needed later by CFileZillaEnginePrivate::ContinueConnect.

Will be fixed in the next version. Please try the upcoming 2009-02-23 build from

Note: See TracTickets for help on using tickets.