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