lftp 4.8.1 crashes upon exit

[Greg Camp]

Release: Ubuntu 18.04.5 LTS
Package: 4.8.1-1ubuntu0.2

lftp 4.8.1 and 4.8.2 have a known bug where it will crash upon exit. This bug was fixed on Oct 3, 2017 and is included in lftp 4.8.3.

This is the error reported on the console:
RateLimit.cc:30: void RateLimit::AddXfer(int): Assertion `xfer_number>=0' failed.

Here is the commit that addresses the issue:
https://github.com/lavv17/lftp/commit/8ac64e9d664270d67fa4b8f75186af0884c030f0

Currently lftp is not usable in scripts due to the segfault / core dump.

[Sebastien Bacher (seb128)]

Thank you for your bug report, the issue seems similar to what was fixed in https://bugs.launchpad.net/ubuntu/+source/lftp/4.8.1-1ubuntu0.2

Do you have a testcase to trigger the issue from a fresh installation?

[Greg Camp (gcamp806)]

This command will trigger the segfault. This is predicated on the <user> having an SSH-enabled account at <host>.

lftp sftp://user@host -e "ls; bye"

The output should be an ls listing of the user's home directory and a clean exit / return to the shell prompt. But instead of clean exit the output will be similar to this:

<directory listing>
lftp: RateLimit.cc:30: void RateLimit::AddXfer(int): Assertion `xfer_number>=0' failed.
Aborted (core dumped)

[Anja Stemme (snowyeti)]

I am not sure if you are using gitlab but for me the following yaml script finally did it:
(maybe as interim until someone fixes the bug)

image: ubuntu:18.04
before_script:
  - apt-get update -qy
  - apt-cache showpkg lftp
  - apt-get install -y lftp
  - apt-get install -y lftp=4.8.1-1ubuntu0.1 --allow-downgrades
  - age=$(stat -c %Y scripts/network.js)

[Launchpad Janitor (janitor)]

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

[Greg Camp (gcamp806)]

I can confirm that downgrading to 4.8.1-1ubuntu0.1 allows the test case to run without triggering a core dump.

Thank you @snowyeti!

[stripTM (striptm)]

I have a similar problem, the transfer is executed, but in the end crash.

I paste the end of a debug run, sorry but the messages are in a Spanish Ubuntu distribution, I hope it is understood.

$ lftp --version
LFTP | Versión 4.8.1 | Copyright (c) 1996-2017 Alexander V. Lukyanov

LTFP es software libre: puede redistribuirlo y modificarlo
bajo los términos de la Licencia pública general GNU tal y como la publica
la Free Software Foundation, en su versión 3 o
(según su criterio) en cualquiera posterior.

Este programa se distribuye con la esperanza de que sea útil,
pero, SIN NINGUNA GARANTÍA, incluso sin garantía de
COMERCIABILIDAD o DE QUE SE AJUSTE A UN PROPÓSITO PARTICULAR. Vea
La Licencia pública general GNU para conocer más detalles.

Debería haber recibido una copia de la Licencia Pública General
con LTFP, en caso contrario, vea <http://www.gnu.org/licenses/>.

Envíe informes de error y preguntas a la lista de correo <email address hidden>.

Bibliotecas utilizadas: GnuTLS 3.5.18, idn2 2.0.4, Readline 7.0, zlib 1.2.11

---- eof
<--- got a packet, length=24, type=101(STATUS), id=24197
---- status code=0(OK), message=Success
---> sending a packet, length=13, type=12(READDIR), id=24454
---> sending a packet, length=13, type=12(READDIR), id=24455
---> sending a packet, length=13, type=4(CLOSE), id=23839
<--- got a packet, length=28, type=101(STATUS), id=24454
---- status code=1(EOF), message=End of file
---- eof
<--- got a packet, length=28, type=101(STATUS), id=23838
---- status code=1(EOF), message=End of file
<--- got a packet, length=24, type=101(STATUS), id=24357
---- status code=0(OK), message=Success
---> sending a packet, length=13, type=4(CLOSE), id=24456
<--- got a packet, length=28, type=101(STATUS), id=24455
---- status code=1(EOF), message=End of file
<--- got a packet, length=24, type=101(STATUS), id=23839
---- status code=0(OK), message=Success
<--- got a packet, length=24, type=101(STATUS), id=24456
---- status code=0(OK), message=Success
---- Desconectándose...
---- Desconectándose...
---- Desconectándose...
---- Desconectándose...
---- Desconectándose...
lftp: RateLimit.cc:30: void RateLimit::AddXfer(int): La declaración `xfer_number>=0' no se cumple.
Abortado (`core' generado)

[Nicolás Alvarez (nicolas-alvarez)]

In my particular case, it *started* crashing after upgrading from 4.8.1-1ubuntu0.1 to 4.8.1-1ubuntu0.2.

With 4.8.1-1ubuntu0.1:
lftp -e 'connect sftp://10.0.2.2 -u nicolas,password42;ls /tmp;exit' # OK
lftp -e 'connect sftp://10.0.2.2 -u nicolas,password42;ls /tmp/ssltest;exit' # crash
lftp -e 'get gnu/glibc/nss_db-2.2.tar.gz;exit' ftp.gnu.org # crash, this was the LP:1902832 testcase

With 4.8.1-1ubuntu0.2:
lftp -e 'connect sftp://10.0.2.2 -u nicolas,password42;ls /tmp;exit' # crash (regression)
lftp -e 'connect sftp://10.0.2.2 -u nicolas,password42;ls /tmp/ssltest;exit' # crash
lftp -e 'get gnu/glibc/nss_db-2.2.tar.gz;exit' ftp.gnu.org # OK (fixed)

However, I think the first case worked on 0.1 out of sheer memory-layout chance, because valgrind shows errors on both versions.

What makes it crash or not may even depend on the length of the output (and thus the contents of the remote server). And I have sometimes seen "lftp: RateLimit.cc:30: void RateLimit::AddXfer(int): Assertion `xfer_number>=0' failed." and other times only "Segmentation fault". But valgrind should reliably show that corruption happened whether it crashes in practice or not.

With 4.8.1-1ubuntu0.1:
$ valgrind lftp -e 'connect sftp://10.0.2.2 -u nicolas,longpassword42;ls /tmp;exit'
[trim directory listing]
==4276== Invalid read of size 4
==4276== at 0x2184B0: RateLimit::~RateLimit() (in /usr/bin/lftp)
==4276== by 0x218B18: xmap_p<RateLimit>::~xmap_p() (in /usr/bin/lftp)
==4276== by 0x6224160: __run_exit_handlers (exit.c:108)
==4276== by 0x6224259: exit (exit.c:139)
==4276== by 0x6202BFD: (below main) (libc-start.c:344)
==4276== Address 0x8053cd0 is 16 bytes inside a block of size 88 free'd
==4276== at 0x4C3323B: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4276== by 0x218B25: xmap_p<RateLimit>::~xmap_p() (in /usr/bin/lftp)
==4276== by 0x6224160: __run_exit_handlers (exit.c:108)
==4276== by 0x6224259: exit (exit.c:139)
==4276== by 0x6202BFD: (below main) (libc-start.c:344)
==4276== Block was alloc'd at
==4276== at 0x4C3217F: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4276== by 0x218A09: RateLimit::init(RateLimit::level_e, char const*) (in /usr/bin/lftp)
==4276== by 0x218A2C: RateLimit::init(RateLimit::level_e, char const*) (in /usr/bin/lftp)
==4276== by 0x211018: SFtp::Do() (in /usr/bin/lftp)
==4276== by 0x1A97C4: SMTask::ScheduleThis() (in /usr/bin/lftp)
==4276== by 0x1A99D0: SMTask::Schedule() (in /usr/bin/lftp)
==4276== by 0x16614C: Job::WaitDone() (in /usr/bin/lftp)
==4276== by 0x15CBE3: main (in /usr/bin/lftp)
==4276==
==4276== Invalid read of size 8
==4276== at 0x2184B5: RateLimit::~RateLimit() (in /usr/bin/lftp)
==4276== by 0x218B18: xmap_p<RateLimit>::~xmap_p() (in /usr/bin/lftp)
==4276== by 0x6224160: __run_exit_handlers (exit.c:108)
==4276== by 0x6224259: exit (exit.c:139)
==4276== by 0x6202BFD: (below main) (libc-start.c:344)
==4276== Address 0x8053cc8 is 8 bytes inside a block of size 88 free'd
==4276== at 0x4C3323B: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4276== ...

[Nicolás Alvarez (nicolas-alvarez)]

I applied the mentioned commit (8ac64e9d66) and tried several commands under valgrind (including the exact one that was failing in production servers), it appears it does fix the problem. But I wouldn't call it an exhaustive test :)

[George Kissandrakis (gkissand)]

any update on this?
I retested it after upgrading libc6, as mentioned to other bug reports, but the problem remains

[Doyle Briley (brileyd)]

I can confirm downgrading to 4.8.1-1ubuntu0.1 allows my script to complete without the error.

[pjv (02-cyberplexus)]

Sorry, but what would it take to upgrade the version of lftp for bionic to version 4.8.4 or higher to fix this bug that has been sitting here confirmed since 2020? Is that a big deal?

[Michael Brohl (mbrohl)]

Yes please lftp to a version where this bug ist fixed. Thank you!