Re: [bug-inetutils] inetutils 1.9.1-4: ftp "get" command occasionally dumps core,

[Mats Erik Andersson]

Hello again,

måndag den  2 september 2013 klockan 18:52 skrev Glenn Golden detta:
> --
> ==8485== Invalid write of size 1
> ==8485==    at 0x804F219: domacro (domacro.c:130)
> ==8485==    by 0x8053E27: cmdscanner (main.c:372)
> #
> # This one looks like fallout from the above.
> #
> ==8485== Invalid write of size 1
> ==8485==    at 0x804F23B: domacro (domacro.c:136)
> ==8485==    by 0x8053E27: cmdscanner (main.c:372)
> #
> # No clue on these, which are all in slurpstring(). Honestly, I just don't 
> have
> # the patience to go thru code which is written based on an FSM which I don't 
> have
> # the diagram of in front of me. :)
> #
> ==8485== Invalid read of size 1
> ==8485==    at 0x805406E: slurpstring (main.c:498)
> ==8485==    by 0x8053ED8: makeargv (main.c:398)
> ==8485==    by 0x804F242: domacro (domacro.c:137)
> ==8485== 
> ==8485== Invalid read of size 1
> ==8485==    at 0x8054098: slurpstring (main.c:508)
> ==8485==    by 0x8053ED8: makeargv (main.c:398)
> ==8485==    by 0x804F242: domacro (domacro.c:137)
> ==8485== 
> ==8485== Invalid read of size 1
> ==8485==    at 0x8053FD9: slurpstring (main.c:464)
> ==8485==    by 0x8053ED8: makeargv (main.c:398)
> ==8485== 
> ==8485== Invalid read of size 1
> ==8485==    at 0x8053F0F: slurpstring (main.c:415)
> ==8485==    by 0x8053ED8: makeargv (main.c:398)
> ==8485== 
> ==8485== Invalid read of size 1
> ==8485==    at 0x8053F19: slurpstring (main.c:415)
> ==8485==    by 0x8053ED8: makeargv (main.c:398)
> ==8485==    by 0x804F242: domacro (domacro.c:137)
> ==8485== 
> ==8485== Invalid read of size 1
> ==8485==    at 0x8053F80: slurpstring (main.c:435)
> ==8485==    by 0x8053ED8: makeargv (main.c:398)
> ==8485==    by 0x804F242: domacro (domacro.c:137)
> 

The above are all expected from my manual analysis that
lead me to a series of patches against "ftp" in Git HEAD,
and which were made public yesterday.

The problems were due to the variables "line", "line2",
and "tokval" being static and of insufficient length.

> #
> # This one is in the region of cmdscanner() that you were concerned about (I 
> think):
> #     (*c->c_handler) (margc, margv);
> #
> ==8485== Invalid read of size 1
> ==8485==    at 0x402BF53: __GI_strlen (in 
> /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
> ==8485==    by 0x40F1B0D: puts (in /usr/lib/libc-2.17.so)
> ==8485==    by 0x8053E27: cmdscanner (main.c:372)
> #
> ==8485== Invalid read of size 1
> ==8485==    at 0x40FB6D8: _IO_file_xsputn@@GLIBC_2.1 (in 
> /usr/lib/libc-2.17.so)
> ==8485==    by 0x40F1BAE: puts (in /usr/lib/libc-2.17.so)
> ==8485==    by 0x804F2E7: domacro (domacro.c:161)
> ==8485==    by 0x8053E27: cmdscanner (main.c:372)
> ==8485== 
> ==8485== Invalid read of size 1
> ==8485==    at 0x40FB6EB: _IO_file_xsputn@@GLIBC_2.1 (in 
> /usr/lib/libc-2.17.so)
> ==8485==    by 0x40F1BAE: puts (in /usr/lib/libc-2.17.so)
> ==8485==    by 0x804F2E7: domacro (domacro.c:161)
> ==8485==    by 0x8053E27: cmdscanner (main.c:372)
> ==8485== 
> ==8485== Invalid read of size 4
> ==8485==    at 0x410862C: __GI_mempcpy (in /usr/lib/libc-2.17.so)
> ==8485==    by 0x40FB634: _IO_file_xsputn@@GLIBC_2.1 (in 
> /usr/lib/libc-2.17.so)
> ==8485==    by 0x40F1BAE: puts (in /usr/lib/libc-2.17.so)
> ==8485==    by 0x804F2E7: domacro (domacro.c:161)
> ==8485==    by 0x8053E27: cmdscanner (main.c:372)
> ==8485== 
> ==8485== Invalid read of size 1
> ==8485==    at 0x805403A: slurpstring (main.c:480)
> ==8485==    by 0x8053ED8: makeargv (main.c:398)
> ==8485==    by 0x804F242: domacro (domacro.c:137)

Caused by the mistake just mentioned.

> # Summary of leaks, etc. after program exits.
> # 
> ==8485== HEAP SUMMARY:
> ==8485==     in use at exit: 56,677 bytes in 182 blocks
> ==8485==   total heap usage: 360 allocs, 178 frees, 77,494 bytes allocated
> ==8485== 
> ==8485== 10 bytes in 1 blocks are definitely lost in loss record 4 of 35
> ==8485==    at 0x402B6A8: malloc (in 
> /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
> ==8485==    by 0x80563AF: xmalloc (in 
> /home/xxx/src/abs/inetutils/src/inetutils-1.9.1/ftp/ftp)
> ==8485==    by 0x804F9CB: login (ftp.c:273)
> ==8485==    by 0x804A955: setpeer (cmds.c:245)
> ==8485==    by 0x8053B6D: main (main.c:244)

If you execute this

   $ ./tests/localhost
   localhost: charybdis

do you get your host name without a corresponding domain?
If so, "ftp/ruserpass.c: 129  xstrdup()" allocates memory
that is never later released.

On a FreeBSD system, building Inetutils from Git HEAD,
running valgrind on ftp like you suggested

    $ valgrind --leak-check=yes ./ftp/ftp ftp.archlinux.org

 and with netrc file

    default
    macdef egen
    cd "/sources/packages"
    lcd /tmp
    get xmltoman-0.4-1.src.tar.gz

produces no intermediary access violations, and the summary
claims there to be no lost memory at all.

Since inetutils-1.9.1 cannot be built on FreeBSD-9.1
I have no means to make a comparison using this machine.

The matter you found with getaddrinfo() clearly indicates
that at least one issue is caused beyond my control, namely
in eglibc-2.17 in use by Arch Linux. How can we insure that
the library is not causing other issues during your execution?

The fact that wrapping ftp within valgrind actually did avoid
one persistent segmentation fault, indicates to me that there
might well be something foul on Arch Linux in your case. I run
a virtualized instance of Arch Linux amd64 in VirtualBox on
OpenSolaris as comparison. Do you use i386 or amd64?

Best regards for now,
  Mats E A