#11710 closed Bug report (fixed)
After updating client to version 3.36.0 it routinely crashes retrieving directory listing from one site
Reported by: | Pete Maclean | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | FileZilla Client |
Keywords: | crash | Cc: | |
Component version: | 3.36.0 | Operating system type: | Windows |
Operating system version: | Windows 7 Professional SP1 |
Description
I routinely use FileZilla client with two FTP servers. Immediately after updating the client to version 3.36.0 it started routinely crashing while "Retrieving directory listing..." from one of these servers. With the other server, I see no problem.
Attachments (7)
Change History (30)
by , 6 years ago
Attachment: | FileZilla.log added |
---|
comment:1 by , 6 years ago
Status: | new → moreinfo |
---|
Please enable logging to file in the settings dialog of FileZilla and restart FileZilla. Next, enable "Show raw directory listings" on the debug page in the settings dialog and then connect to the server that makes FileZilla crash.
Please attach the resulting log file to this ticket.
by , 6 years ago
Attachment: | FileZilla.2.log added |
---|
comment:4 by , 6 years ago
Status: | new → moreinfo |
---|
The log is uneventful, nothing unusual in it.
There should crash dumps of FileZilla in the %LOCALAPPDATA%\CrashDumps directory, please attach the most recent dump from FileZilla to this ticket.
by , 6 years ago
Attachment: | libgnutls-30.dll added |
---|
comment:5 by , 6 years ago
The crash happens someplace in GnuTLS, unfortunately the optimizer has made the callstack useless.
Please replace the libgnutls-30.dll in the FileZilla directory with the attached file, it is built with -O0, then try to connect again. As there are no functional changes it should crash again. Once more, please attach the resulting dump from using the debug dll.
by , 6 years ago
Attachment: | filezilla.exe.34616.dmp added |
---|
Crash dump from run using debug version of libgnutls-30.dll
comment:6 by , 6 years ago
I have no idea what could be causing this. It looks like it's something unique to your system as there are no further reports of similar issues.
comment:7 by , 6 years ago
The working hypothesis is a corrupted CA or CRL in the system trust store that somehow trips up GnuTLS.
Please run the attached diagnostics tool. It will prompt you to enter an output file name into which it will dump the trust anchors. Please attach the generated file to this ticket.
by , 6 years ago
Attachment: | diagnostics.exe added |
---|
comment:9 by , 6 years ago
Whoah, that's a large file. Over here the diagnostic logs are a mere 71KiB.
This will be interesting to analyze.
comment:10 by , 6 years ago
In case it may help, I ran FileZilla under windbg and recorded the following information about the fault:
(1197c.119fc): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
* WARNING: Unable to verify timestamp for C:\Program Files\FileZilla FTP Client\libgnutls-30.dll
* ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Program Files\FileZilla FTP Client\libgnutls-30.dll -
libgnutls_30!gnutls_sign_get_pk_algorithm+0x1c0c2:
0000000063aa04f2 488b5f60 mov rbx,qword ptr [rdi+60h] ds:feeefeee
feeeff4e=????????????????
0:001> r
rax=0000000000000002 rbx=000000000b3617f0 rcx=000000000b3617f0
rdx=0000000000000000 rsi=feeefeeefeeefeee rdi=feeefeeefeeefeee
rip=0000000063aa04f2 rsp=00000000038bf8d0 rbp=000000000b3617f0
r8=0000000000008000 r9=feeefeeefeeefeee r10=0000000001220158
r11=00000000038bf508 r12=0000000000000001 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na po nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010286
libgnutls_30!gnutls_sign_get_pk_algorithm+0x1c0c2:
0000000063aa04f2 488b5f60 mov rbx,qword ptr [rdi+60h] ds:feeefeee
feeeff4e=????????????????
Both RBX and RCX point to memory filled with the value in RSI and RDI.
comment:11 by , 6 years ago
The good news: With this diagnostics file I managed to reproduce the issue. It seems to be triggered by the CRLs. Not with a single CRL though, only when loading multiple of them. Very bizarre.
comment:13 by , 6 years ago
Tim, glad to hear it. Jolly good.
I tried to add a very brief comment prior to this one and got caught in an apparently infinite Captcha loop. Something suspected that what I wrote might be spam and I was asked to do some arithmetic calculations. I must have done about 20 and, in spite of (I am sure) answering them all correctly, it just kept asking again and again. Somebody should look into this, I think!
comment:14 by , 6 years ago
Since this is a user-writable problem reporting system, the Bayes classifier thinks only spambots write positive comments. The spam score was so high, not even the captcha was redeeming it ;)
comment:15 by , 6 years ago
Upstream report: https://gitlab.com/gnutls/gnutls/issues/554 (confidential for now)
comment:16 by , 6 years ago
Status: | new → moreinfo |
---|
Please try the latest nightly build for 64bit Windows.
comment:18 by , 6 years ago
Status: | moreinfo → new |
---|
Bingo! This build solves my problem and appears to be working well. Many thanks, Tim.
comment:19 by , 6 years ago
Status: | new → moreinfo |
---|
How is the performance with that build? After having taken a note of the performance, please also try today's nightly and compare the performance.
comment:20 by , 6 years ago
Status: | moreinfo → new |
---|
I have not used it extensively but I did have an impression that performance was sluggish. I will try with the latest and let you know.
comment:23 by , 6 years ago
Is anyone else also getting system errors in ncryptprov.dll or is that just me?
I'm just trying to figure out if the problem is limited to FileZilla or am I having multiple different problems.
This is the log for a connection and directory-listing retrieval attempt that fails