#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 |
Description
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)
Change History (9)
comment:1 by , 16 years ago
| Status: | new → moreinfo |
|---|
comment:2 by , 16 years ago
| Status: | moreinfo → new |
|---|
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 , 16 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 , 16 years ago
| Status: | new → moreinfo |
|---|
Set debug level to 4 and enable logging to file. Make it crash. Then attach logfile here.
comment:5 by , 16 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?
comment:6 by , 16 years ago
| Operating system version: | XP SP3 → Vista SP1 |
|---|---|
| Status: | moreinfo → new |
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 , 16 years ago
| Owner: | set to |
|---|---|
| Priority: | normal → high |
| Status: | new → accepted |
Funny thing, setting my own language to Italian and I could immediately reproduce it.
comment:8 by , 16 years ago
| Resolution: | → fixed |
|---|---|
| Status: | accepted → closed |
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 http://filezilla-project.org/nightly.php
Which version of FileZilla?
Which protocol are you using?