This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch gdbserver 7.6.1 only] Fix fd leak regression
- From: Pedro Alves <palves at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 29 Aug 2013 15:17:40 +0100
- Subject: Re: [patch gdbserver 7.6.1 only] Fix fd leak regression
- Authentication-results: sourceware.org; auth=none
- References: <20130829111053 dot GA25662 at host2 dot jankratochvil dot net> <521F3B71 dot 1010007 at redhat dot com> <20130829130359 dot GA31063 at host2 dot jankratochvil dot net>
On 08/29/2013 02:03 PM, Jan Kratochvil wrote:
> On Thu, 29 Aug 2013 14:15:45 +0200, Pedro Alves wrote:
>> (We could also just mark the sockets as SOCK_CLOEXEC, I think?
>> Though that's "only" since Linux 2.6.27, so I've no objection with
>> going this route.)
>
> * There is no real need for SOCK_CLOEXEC, GDB benefits from it for Python
> threads (possibly calling their own fork+exec) but those do not happen for
> gdbserver.
I suspect we'll have to revisit this at some point (years from now),
but yeah, agreed.
>
> * It would not work for old/non-Linux OSes which does not matter much but it
> is still rather a disadvantage.
*nod*
> gdb/gdbserver/
> 2013-08-29 Jan Kratochvil <jan.kratochvil@redhat.com>
>
> PR server/15604
> * linux-low.c
> (linux_create_inferior) <pid == 0 && !remote_connection_is_stdio ()>:
> Close LISTEN_DESC and optionally REMOTE_DESC.
> (lynx_create_inferior) <pid == 0 && !remote_connection_is_stdio ()>:
> Close LISTEN_DESC and optionally REMOTE_DESC.
> * remote-utils.c (remote_desc, listen_desc): Remove static qualifier.
> * server.h (remote_desc, listen_desc): New declaration.
> * spu-low.c
> (spu_create_inferior) <pid == 0 && !remote_connection_is_stdio ()>:
> Close LISTEN_DESC and optionally REMOTE_DESC.
Thanks, this looks good to me.
> +set test "system fd behavior is known"
> +set status [remote_exec target "[standard_output_file $testfile]"]
> +if { [lindex $status 0] == 0 } {
> + pass $test
> +} else {
> + fail $test
> +}
> +remote_exec target "ls -l /proc/self/fd/"
Before gdbserver's fix, do we get one extra fd from the dejagnu
leak, and another extra from gdbserver's leak? What if we made
$testfile count open fds, and then compare that between running
under gdb/gdbserver and just under remote_exec ?
--
Pedro Alves