bug-inetutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-inetutils] inetutils 1.9.1-4: ftp "get" command occasionally du


From: Mats Erik Andersson
Subject: Re: [bug-inetutils] inetutils 1.9.1-4: ftp "get" command occasionally dumps core,
Date: Sun, 1 Sep 2013 21:28:25 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

söndag den  1 september 2013 klockan 11:51 skrev Glenn Golden detta:
>
> Also: This segfault occurs for me with several servers, not just
> ftp.archlinux.org.  In fact, I discovered it using a server on my
> local network here, and that server runs each "get" in about 1 second.
> So any connection timeout issue seems an unlikely source of the segfault
> I'm seeing.

I have lowered the timeout on my servers in order to reduce the
delay needed when provoking "my" core dump.

> I did install your patch to domacro.c, but it has no effect on the segfault
> that I observe.

This is relevant info. When I use gdb on my core dump, I see that
the last identified call was to domacro(), which is why the patch
looks like it did. Can you fire up gdb on your core to give me
a view of your call stack:

     $ gdb  your_ftp_executable  your_dumped_core
     (gdb) bt
     .....

> > Positioning of printf-probes could preferable be done close to "c_handler"
> > and "connected" as well as loops in their vicinity. This would suggest that
> > "ftp/domacro.c" and "ftp/main.c" are the most relevant files.
> > 
> 
> Unfortunately, I don't have enough knowledge of the context of these functions
> to understand exactly where and what you would like to printf.

I usually insert statements like

    printf("mats: domacro.c %d\n", __FILE__);

when dealing with interactive applications. Nothing fancy, just
enough to find which stages are actually executed.

The suggested strings were just to find relevant positions:

    $ grep -n -r -e '\<c_handler\>' -e '\<connected\>'  ftp/

> If you can > provide a bit more info on what you're seeking to display,
> or even better, a patchfile with printfs installed, it would be helpful.

The most probable causes seem to be double-free as well as strcpy()
access errors, or generally, some trespassing into protected memory
which was not allocated by readline() or getline() for the global
variable "line" and its local placeholder, but I am guessing until
you inform me about the call stack.

> Btw, side issue: For some reason, I did not receive a copy of the message from
> which the above quotes are drawn, which on the ML is dated
> 
>     Sat, 31 Aug 2013 03:59:57 +0200

My server claims that at 31 Aug 2013 04:00:09 the server at "mail.indra.com"
accepted my message on behalf of "gdg at zplane.com". That was seven seconds
later than "eggs.gnu.org" did the same an behalf of the sendlist.
Your address was the primary recipient, while bug-inetutils was CC'ed.
Some servers have recently been rejecting me because of Spamhaus' PBL
view on my address block, but "mail.indra.com" did not object.

Best regards,
  Mats Erik Andersson, committed member of GNU Inetutils!



reply via email to

[Prev in Thread] Current Thread [Next in Thread]