filezilla crashed with SIGABRT in start_thread()

This issue only seems to be present on xubuntu after a variety of testing, but further testing will occur.

Status changed to 'Confirmed' because the bug affects multiple users.

This also happens on kubuntu (24.04)

Just now can confirm a similar crash on kubuntu 24.04 development branch.

Ubuntu 24.04 development branch @ 17/4/2024

I filed a private crash bug before on filezilla

this bug only happens for me when the dir contains several files

with an .mkv file only, it seems to upload for me

but if an .mkv and a .txt file inside the dir, filezilla crashes

i have this problem on ubuntu 24.04 beta when i upload a file
no matter the file, it crashes immediately

https://trac.filezilla-project.org/ticket/13056

Thank you for your report!

However, processing it in order to get sufficient information for the
developers failed as the report has a core dump which is invalid. The
corruption may have happened on the system which the crash occurred or during
transit.

Thank you for your understanding, and sorry for the inconvenience!

Just for interest sake I found Filezilla 3.66.5 working perfectly on Debian testing.

the problem comes from filezilla directly, they identified the problem and produced a fix, if you read the topic on their bugtracker

https://trac.filezilla-project.org/ticket/13056

The fix was done 3 weeks ago, how long will it roughly take to filter through to Ubuntu?

Changing to the libfilezilla package.

Preparing a Stable Release Update (SRU) currently.

[ IMPACT ]

Stops users uploading files (various file types or multiple) with filezilla.

[ TEST PLAN ]

Testing was done on local and remote workstations.

[ OTHER INFO ]

This is a low impact fix and regression possibilities are low.

Hey, thanks for taking the time to make the patch! There are some problems that I noticed that I think you might want to fix so that we can get this into Ubuntu.

Firstly, the SRU paperwork.

The bug you're fixing may very well be a good one to SRU a fix for, but the SRU justification in your comment above is insufficient. Please read https://wiki.ubuntu.com/StableReleaseUpdates carefully, especially section 4 "Procedure". In particular:

* The impact section could be made more verbose so that the SRU team has an understanding of *why* something is going wrong, not just *what* is going wrong.

* The test plan is inadequate. We need a full, step-by-step list of instructions on how someone other than yourself should set up their systems for testing, and then the exact steps to take for testing. This doesn't have to be crazily detailed (you don't have to describe every single button and keystroke to use), but it needs to be detailed enough that someone else can do it themselves and verify both that the old version is broken and that the new version is fixed.

* The "Where problems could occur" section has been left out entirely. This section is mandatory, as any fix, **no matter how small**, comes with regression potential. (This is slightly hard to imagine until you've mangled packages the way I have. :P) Show that you're "expecting the unexpected" here.

* The "OTHER INFO" section appears to contain info that was intended for "Where problems could occur". The info in this section is insufficient for a "Where problems could occur" section as it simply states that the regression possibility is low, rather than describing what could go wrong. According to the SRU process documentation, "This (the "Where problems could occur" section) must **never** be "None" or "Low", or entirely an argument as to why your upload is low risk.".

* The SRU template goes in the bug report description, not in a comment. Usually the way I do this without overwriting old changes is I edit the bug report, leave the original bug report at the bottom, and place the SRU paperwork at the top.

Secondly, the patch itself has some problems:

+libfilezilla (0.46.0-3.1build4) noble; urgency=medium
                         ^^^^^^
* This version number is wrong. You're introducing an Ubuntu delta, so you need an "ubuntu" version number here, not a "build" version number. According to https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging (which is linked to from the SRU documentation), the version number that should be used here is 0.46.0-3.1ubuntu0.1. (And yes, I think that my suggested version number looks as insane as you think it does. Ubuntu version numbers are hard.)

* Speaking of an Ubuntu delta, when you make Ubuntu-specific changes to a package, you need to modify debian/control to show that the package has Ubuntu changes. To do this, the 'Maintainer' field in debian/control needs to be converted to an 'XSBC-Original-Maintainer' field, and a new 'Maintainer' field put in its place identifying the Ubuntu Developers as being the maintainer, like so:
    Maintainer: Ubuntu Developers <email address hidden>

* The patch is missing Debi...

Attached is new debdiff that I hope meets with approval.

[ Impact ]

File reading is not correctly performed and leaves the dependent package
filezilla in a state where uplaoding of files causes error and crashes the
application.

[ Test Plan ]

* Create vanilla[1] Virtual Machines (VMs) - Ubuntu 24.04.

* Test the bug exists in the VMs.
  - Setup connections to my kathenas server.
  - Uplod and dowload a variety of file types.
    # *.txt
    # *.mp4
    # *.mp3
    # *.ogg
    and others.

  * Create vanilla[1] Virtual Machines (VMs) - Ubuntu 24.04.

  * Test the bug is fixed with submitted patch built into package and installed
    in the VMs.
  - Setup connections to my kathenas server.
  - Uplod and dowload a variety of file types.
    # *.txt
    # *.mp4
    # *.mp3
    # *.ogg
    and others.

  * Tests performed over days and conencting randomly to perform upload and
    download tests.

  * Check for bug feedback when built and enters proposed updates repository.

[ Where problems could occur ]

The patch allows for correct operation by changing the IO behaviour and alters
no other operation of the application. The patch has negligible risk for the users
of this library and the dependent package filezilla.

Only filezilla consumes this library and there is no risk to any other
library/application.

[ Other Info ]

None.

[1] These are installations that have only Ubuntu repositories and no
applications installed other than the default install ones and the
package being test.

While I am the Debian maintainer for libfilezilla and filezilla, I help with these in Ubuntu on my own dime. If anyone wishes to help and allow me more time to do this type of work, you can donate via the link below.

https://buymeacoffee.com/kathenasorg

I see the patch is applied in oracular (new upstream release 0.47.0), marking that task fix released.

Copying over comment #18 to the bug description as it has the SRU template.

Let me try to simplify the test case to something that can be done without external dependencies.

I also fixed the bug reference in the changelog, and feel free to modify the test plan if you don't agree with my changes.

Sponsored for noble, thanks for the debdiff!

Uploading libfilezilla_0.46.0-3.1ubuntu0.1.dsc
Uploading libfilezilla_0.46.0-3.1ubuntu0.1.debian.tar.xz
Uploading libfilezilla_0.46.0-3.1ubuntu0.1_source.buildinfo
Uploading libfilezilla_0.46.0-3.1ubuntu0.1_source.changes

Hello Phil, or anyone else affected,

Accepted libfilezilla into noble-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libfilezilla/0.46.0-3.1ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-noble to verification-done-noble. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-noble. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Yeah, it fixes this bug for me.
I have tested the uploading of *.txt, *.avi, *.zip, *.jpg files on SFTP server.

dpkg -l | grep filezilla
ii filezilla 3.66.5-2build2 amd64 Full-featured graphical FTP/FTPS/SFTP client
ii filezilla-common 3.66.5-2build2 all Architecture independent files for filezilla
ii libfilezilla-common 0.46.0-3.1ubuntu0.1 all build high-performing platform-independent programs (translations)
ii libfilezilla-dev:amd64 0.46.0-3.1ubuntu0.1 amd64 build high-performing platform-independent programs (development)
ii libfilezilla42t64:amd64 0.46.0-3.1ubuntu0.1 amd64 build high-performing platform-independent programs (runtime lib)

It took me a while until I understood how to get the new files, but now I can also confirm Filezilla does no longer crash when transferring files via SFTP.

Thank you very much for the work!

dpkg -l | grep filezilla
ii filezilla 3.66.5-2build2 amd64 Full-featured graphical FTP/FTPS/SFTP client
ii filezilla-common 3.66.5-2build2 all Architecture independent files for filezilla
ii libfilezilla-common 0.46.0-3.1ubuntu0.1 all build high-performing platform-independent programs (translations)
ii libfilezilla-dev:amd64 0.46.0-3.1ubuntu0.1 amd64 build high-performing platform-independent programs (development)
ii libfilezilla42t64:amd64 0.46.0-3.1ubuntu0.1 amd64 build high-performing platform-independent programs (runtime lib)
ii libfilezilla42t64-dbgsym:amd64 0.46.0-3.1ubuntu0.1 amd64 debug symbols for libfilezilla42t64

I have this bug, and the 3.66.5-2build2 package doesn't fix it.

ii filezilla 3.66.5-2build2 amd64 Full-featured graphical FTP/FTPS/SFTP client
ii filezilla-common 3.66.5-2build2 all Architecture independent files for filezilla
ii libfilezilla-common 0.46.0-3.1build3 all build high-performing platform-independent programs (translations)
ii libfilezilla42t64:amd64 0.46.0-3.1build3 amd64 build high-performing platform-independent programs (runtime lib)

I have enabled "noble-proposed", but no dice.

Instead, compiling the source code of filezilla and libfilezilla from the official page (3.67.0 and 0.47.0) does work fine.

Sergio, it is libfilezilla 0.46.0-3.1ubuntu0.1 that is in the noble-proposed repository that is the fix for the issue.

Sergio, when installing the package, try passing "-t noble-proposed" to the apt command line.