Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#35898 - [inetutils 1.9.1-4] ftp "get" command dumps core

Attached to Project: Arch Linux
Opened by Glenn (grepfor) - Saturday, 22 June 2013, 20:15 GMT
Last edited by Eric Belanger (Snowman) - Friday, 20 September 2013, 17:39 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Eric Belanger (Snowman)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No


Description: Executing ftp "get" sometimes results in a coredump in libc. The attachment shows a full minimal example sequence, with verbosity enabled. (Filenames and other private info replaced by "xxxx".)

Additional info:
* Package: inetutils 1.9.1-4

Steps to reproduce: See attachement. That example is 100% reproducible.
This task depends upon

Closed by  Eric Belanger (Snowman)
Friday, 20 September 2013, 17:39 GMT
Reason for closing:  Fixed
Additional comments about closing:  inetutils
Comment by Eric Belanger (Snowman) - Sunday, 23 June 2013, 12:55 GMT
It doesn't seg fault with (you could try it login as anonymous, no password). Did you tried different servers?
Comment by Glenn (grepfor) - Sunday, 23 June 2013, 14:34 GMT
No, the only server I've tried it with is my own internal one, which is what is reflected in the minimal example dialog. That server is a windows-based product, FileZilla. I'll do some investigating with server and see if I can reproduce the problem there and let you know what I find.

Comment by Glenn (grepfor) - Sunday, 23 June 2013, 15:13 GMT
Hi Eric,

Was able to reproduce the problem using server.

Below is a .netrc entry that seems to reproduce the segfault consistently, upon executing the "get_files" macro. That macro simply runs four "get" commands in a row. Why four? Because it often does not fail until several "get"s are done in a row. The fourth one was most often the killer, but not consistently. I did observe it fail once on the first "get".

The attachment ("example2.txt") shows a typical result, failing on the 4th "get".

NOTE: The file and directory chosen for download was entirely arbitrary. Just picked a dir/file of roughly the same size as the ones I was using in my original example.

================ .netrc entry for reproducing problem on server ============
login anonymous
macdef init
cd "/sources/packages"

macdef get_files
cd "/sources/packages"
get zziplib-0.13.62-1.src.tar.gz
get zziplib-0.13.62-1.src.tar.gz
get zziplib-0.13.62-1.src.tar.gz
get zziplib-0.13.62-1.src.tar.gz

Comment by Glenn (grepfor) - Saturday, 17 August 2013, 12:45 GMT
Status ping: Were you able to reproduce this using the .netrc script provided in the last post?
Comment by Eric Belanger (Snowman) - Saturday, 17 August 2013, 19:19 GMT
Report this upstream. Even if I can reproduce this (didn't try the .netrc), I can't fix this.
Comment by Glenn (grepfor) - Sunday, 18 August 2013, 00:26 GMT

Btw, not a criticism or complaint but... what is the proper way to avoid the delay (from 23-June until now) in a report like this? Or is it just a matter of squeaky-wheel gets attention?

Again, not complaining, just asking so I know better next time.

Comment by Eric Belanger (Snowman) - Sunday, 18 August 2013, 03:52 GMT
Sorry about that. I should've asked to report upstream much earlier. Honestly, I was a bit suprised when I saw the June 23 date. I probably meant to try the .netrc and forgot. Then, this bug report fell off the radar.
Comment by Glenn (grepfor) - Sunday, 18 August 2013, 21:00 GMT
No problem, I probably should have pinged about it earlier.

I'll post the upstream bug # once I get it from
Comment by Glenn (grepfor) - Friday, 23 August 2013, 17:15 GMT
Eric, fyi, fwiw: I sent two bug reports to <>, one on 17-Aug, another on 21-Aug, the latter one asking for confirmation of receipt of the first one (in case it got spam-filtered).

Looking now at the ML archives -- I should have done that first, would have seen the first message there -- I see both messages.

Summertime = vacationtime I guess... ?

Just lettin' ya know.

Comment by Glenn (grepfor) - Friday, 30 August 2013, 23:37 GMT

During ML discusstion of this bug with the pkg maintainer (Mats Erik Andersson) he mentioned the following tangentially:

> (Side note: inetutils-telnetd is severely misbehaving on
> Arch Linux, but not on Debian, BSD or Solaris. Is this
> known to your collegues?)

Just letting you know about it. If you want more detail check with him on the ML I guess.
Comment by Glenn (grepfor) - Wednesday, 11 September 2013, 00:44 GMT
Hi Eric,

The inetutils maintainer has some concerns regarding a specific library (eglibc-2.17) used by Arch that may be implicated in this bug (and possibly some others). Is it possible for you to get involved in answering his questions about this? Also if you have time, could you please attempt to reproduce this segfault on your Arch system. He is unable to reproduce it on several systems that he's tried (not Arch) yet it consistently occurs on all my Arch machines. So it is looking more Arch-specific at this point, although it is not definite.

If you want to familiarize yourself with the background discussion, see the last few messages in the ML. The most relevant is this one:

Comment by Eric Belanger (Snowman) - Thursday, 12 September 2013, 16:48 GMT
I've push a inetutils- package in testing. It uses a git checkout from yesterday which fixes the seg faults here and also according to you on the ML. Thanks for working with upstream on fixing this.
Comment by Glenn (grepfor) - Thursday, 12 September 2013, 20:46 GMT
Eric, please clarify for completeness: 1. Did you get in touch with Mats regarding the eglibc issue? 2. Were you able to get the segfault to occur on your system (prior to the updated version in testing repo)?

Comment by Eric Belanger (Snowman) - Friday, 13 September 2013, 05:00 GMT
1. We do not use eglibc. We only use regular gnu glibc. I intended to contact him but then I saw on the ML that it was fixed with the latest set of patches. As a result, I didn't contacted him.

2. I am able to reproduce the error with the inetutils in core. With the inetutils in testing, the error is gone.