unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#32604: 26.1.50; memory leak in connect_network_socket
@ 2018-09-01  5:38 YAMAMOTO Mitsuharu
  2018-09-01  5:46 ` YAMAMOTO Mitsuharu
  2018-09-02 17:55 ` Noam Postavsky
  0 siblings, 2 replies; 8+ messages in thread
From: YAMAMOTO Mitsuharu @ 2018-09-01  5:38 UTC (permalink / raw)
  To: 32604

In connect_network_socket (in process.c), the memory pointed to
by the variable `sa’ doesn’t seem to be deallocated.

  3328	  struct sockaddr *sa = NULL;
	:
  3347	  while (!NILP (addrinfos))
  3348	    {
	:
  3359	      if (sa)
  3360		free (sa);
  3361	      sa = xmalloc (addrlen);
	:
  3533	    }
	:

The following patch would fix the leak:

diff --git a/src/process.c b/src/process.c
index 676f38446e..e5b70ca058 100644
--- a/src/process.c
+++ b/src/process.c
@@ -3576,6 +3576,8 @@ connect_network_socket (Lisp_Object proc, Lisp_Object addrinfos,
 #endif
     }
 
+  xfree (sa);
+
   if (s < 0)
     {
       const char *err = (p->is_server


Also, line 3359-3361 above could be:
      sa = xrealloc (addrlen);

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

In GNU Emacs 26.1.50 (build 1, x86_64-apple-darwin16.7.0)
 of 2018-09-01 built on YAMAMOTO-no-iMac-5K.local
Repository revision: ac7936cb8f4d4d6706535bfcea0d97741c2ca15f
Windowing system distributor 'The X.Org Foundation', version 11.0.11804000
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --without-ns --without-x-toolkit --without-gnutls
 --with-jpeg=no --with-gif=no --with-tiff=no
 PKG_CONFIG=/opt/local/bin/pkg-config
 PKG_CONFIG_PATH=/usr/lib/pkgconfig:/opt/X11/lib/pkgconfig:/usr/local/lib/pkgconfig
 PKG_CONFIG_LIBDIR= --enable-checking=yes,glyphs
 --enable-check-lisp-object-type CFLAGS=-g'

Configured features:
XPM PNG NOTIFY ACL LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB OLDXMENU
X11 XDBE XIM THREADS

Important settings:
  value of $LANG: ja_JP.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils elec-pair time-date
mule-util japan-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads kqueue
dynamic-setting font-render-setting x multi-tty make-network-process
emacs)

Memory information:
((conses 16 97309 7262)
 (symbols 48 20210 2)
 (miscs 40 64 126)
 (strings 32 28170 1559)
 (string-bytes 1 745551)
 (vectors 16 14728)
 (vector-slots 8 572806 12294)
 (floats 8 54 90)
 (intervals 56 261 13)
 (buffers 992 12))






^ permalink raw reply related	[flat|nested] 8+ messages in thread

* bug#32604: 26.1.50; memory leak in connect_network_socket
  2018-09-01  5:38 bug#32604: 26.1.50; memory leak in connect_network_socket YAMAMOTO Mitsuharu
@ 2018-09-01  5:46 ` YAMAMOTO Mitsuharu
  2018-09-02 17:55 ` Noam Postavsky
  1 sibling, 0 replies; 8+ messages in thread
From: YAMAMOTO Mitsuharu @ 2018-09-01  5:46 UTC (permalink / raw)
  To: 32604

>   3328	  struct sockaddr *sa = NULL;

>   3359	      if (sa)
>   3360		free (sa);
>   3361	      sa = xmalloc (addrlen);

> Also, line 3359-3361 above could be:
>       sa = xrealloc (addrlen);

Oops, I meant

      sa = xrealloc (sa, addrlen);

of course.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#32604: 26.1.50; memory leak in connect_network_socket
  2018-09-01  5:38 bug#32604: 26.1.50; memory leak in connect_network_socket YAMAMOTO Mitsuharu
  2018-09-01  5:46 ` YAMAMOTO Mitsuharu
@ 2018-09-02 17:55 ` Noam Postavsky
  2018-09-03  6:02   ` mituharu
  1 sibling, 1 reply; 8+ messages in thread
From: Noam Postavsky @ 2018-09-02 17:55 UTC (permalink / raw)
  To: YAMAMOTO Mitsuharu; +Cc: 32604

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> In connect_network_socket (in process.c), the memory pointed to
> by the variable `sa’ doesn’t seem to be deallocated.
>
>   3328	  struct sockaddr *sa = NULL;
> 	:
>   3347	  while (!NILP (addrinfos))
>   3348	    {
> 	:
>   3359	      if (sa)
>   3360		free (sa);
>   3361	      sa = xmalloc (addrlen);
> 	:
>   3533	    }
> 	:
>
> The following patch would fix the leak:

> +  xfree (sa);

I think we would need

    record_unwind_protect_ptr (xfree, sa);

to handle the case where an error is signaled.  Similar to how the
socket closing is handled:

      /* Make us close S if quit.  */
      record_unwind_protect_int (close_file_unwind, s);





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#32604: 26.1.50; memory leak in connect_network_socket
  2018-09-02 17:55 ` Noam Postavsky
@ 2018-09-03  6:02   ` mituharu
  2018-09-04 23:19     ` Noam Postavsky
  0 siblings, 1 reply; 8+ messages in thread
From: mituharu @ 2018-09-03  6:02 UTC (permalink / raw)
  To: Noam Postavsky; +Cc: 32604

> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>
>> In connect_network_socket (in process.c), the memory pointed to
>> by the variable `sa’ doesn’t seem to be deallocated.
>>
>>   3328  struct sockaddr *sa = NULL;
>> :
>>   3347  while (!NILP (addrinfos))
>>   3348    {
>> :
>>   3359      if (sa)
>>   3360free (sa);
>>   3361      sa = xmalloc (addrlen);
>> :
>>   3533    }
>> :
>>
>> The following patch would fix the leak:
>
>> +  xfree (sa);
>
> I think we would need
>
>     record_unwind_protect_ptr (xfree, sa);
>
> to handle the case where an error is signaled.  Similar to how the
> socket closing is handled:
>
>       /* Make us close S if quit.  */
>       record_unwind_protect_int (close_file_unwind, s);
>

Indeed.  Could someone double-check the patch below?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

diff --git a/src/process.c b/src/process.c
index 676f38446e..ff53b86844 100644
--- a/src/process.c
+++ b/src/process.c
@@ -3322,6 +3322,7 @@ connect_network_socket (Lisp_Object proc,
Lisp_Object addrinfos,
                         Lisp_Object use_external_socket_p)
 {
   ptrdiff_t count = SPECPDL_INDEX ();
+  ptrdiff_t count1 UNINIT;
   int s = -1, outch, inch;
   int xerrno = 0;
   int family;
@@ -3344,6 +3345,9 @@ connect_network_socket (Lisp_Object proc,
Lisp_Object addrinfos,
   /* Do this in case we never enter the while-loop below.  */
   s = -1;

+  record_unwind_protect_nothing ();
+  count1 = SPECPDL_INDEX ();
+
   while (!NILP (addrinfos))
     {
       Lisp_Object addrinfo = XCAR (addrinfos);
@@ -3356,9 +3360,8 @@ connect_network_socket (Lisp_Object proc,
Lisp_Object addrinfos,
 #endif

       addrlen = get_lisp_to_sockaddr_size (ip_address, &family);
-      if (sa)
-	free (sa);
-      sa = xmalloc (addrlen);
+      sa = xrealloc (sa, addrlen);
+      set_unwind_protect_ptr (count, xfree, sa);
       conv_lisp_to_sockaddr (family, ip_address, sa, addrlen);

       s = socket_to_use;
@@ -3520,7 +3523,7 @@ connect_network_socket (Lisp_Object proc,
Lisp_Object addrinfos,
 #endif /* !WINDOWSNT */

       /* Discard the unwind protect closing S.  */
-      specpdl_ptr = specpdl + count;
+      specpdl_ptr = specpdl + count1;
       emacs_close (s);
       s = -1;
       if (0 <= socket_to_use)
@@ -3591,6 +3594,7 @@ connect_network_socket (Lisp_Object proc,
Lisp_Object addrinfos,
 	  Lisp_Object data = get_file_errno_data (err, contact, xerrno);

 	  pset_status (p, list2 (Fcar (data), Fcdr (data)));
+	  unbind_to (count, Qnil);
 	  return;
 	}

@@ -3610,7 +3614,7 @@ connect_network_socket (Lisp_Object proc,
Lisp_Object addrinfos,
   p->outfd = outch;

   /* Discard the unwind protect for closing S, if any.  */
-  specpdl_ptr = specpdl + count;
+  specpdl_ptr = specpdl + count1;

   if (p->is_server && p->socktype != SOCK_DGRAM)
     pset_status (p, Qlisten);
@@ -3671,6 +3675,7 @@ connect_network_socket (Lisp_Object proc,
Lisp_Object addrinfos,
     }
 #endif

+  unbind_to (count, Qnil);
 }

 /* Create a network stream/datagram client/server process.  Treated







^ permalink raw reply related	[flat|nested] 8+ messages in thread

* bug#32604: 26.1.50; memory leak in connect_network_socket
  2018-09-03  6:02   ` mituharu
@ 2018-09-04 23:19     ` Noam Postavsky
  2018-09-05 23:50       ` YAMAMOTO Mitsuharu
  0 siblings, 1 reply; 8+ messages in thread
From: Noam Postavsky @ 2018-09-04 23:19 UTC (permalink / raw)
  To: mituharu; +Cc: 32604

Looks good to me; a couple of minor suggestions below.

mituharu@math.s.chiba-u.ac.jp writes:

> @@ -3322,6 +3322,7 @@ connect_network_socket (Lisp_Object proc,
> Lisp_Object addrinfos,
>                          Lisp_Object use_external_socket_p)
>  {
>    ptrdiff_t count = SPECPDL_INDEX ();
> +  ptrdiff_t count1 UNINIT;
>    int s = -1, outch, inch;
>    int xerrno = 0;
>    int family;
> @@ -3344,6 +3345,9 @@ connect_network_socket (Lisp_Object proc,
> Lisp_Object addrinfos,
>    /* Do this in case we never enter the while-loop below.  */
>    s = -1;
>
> +  record_unwind_protect_nothing ();
> +  count1 = SPECPDL_INDEX ();

Since we assume a C99 compiler now, you could just do

    ptrdiff_t count1 = SPECPDL_INDEX ();

without having the UNINIT thing.  Also, since free is harmless on a NULL
pointer, you could just record an unwind protect at the top once,
without having the nothing state, I think.





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#32604: 26.1.50; memory leak in connect_network_socket
  2018-09-04 23:19     ` Noam Postavsky
@ 2018-09-05 23:50       ` YAMAMOTO Mitsuharu
  2018-09-06  0:04         ` Noam Postavsky
  0 siblings, 1 reply; 8+ messages in thread
From: YAMAMOTO Mitsuharu @ 2018-09-05 23:50 UTC (permalink / raw)
  To: Noam Postavsky; +Cc: 32604

On Wed, 05 Sep 2018 08:19:48 +0900,
Noam Postavsky wrote:

> 
> Looks good to me; a couple of minor suggestions below.
> 
> mituharu@math.s.chiba-u.ac.jp writes:
> 
> > @@ -3322,6 +3322,7 @@ connect_network_socket (Lisp_Object proc,
> > Lisp_Object addrinfos,
> >                          Lisp_Object use_external_socket_p)
> >  {
> >    ptrdiff_t count = SPECPDL_INDEX ();
> > +  ptrdiff_t count1 UNINIT;
> >    int s = -1, outch, inch;
> >    int xerrno = 0;
> >    int family;
> > @@ -3344,6 +3345,9 @@ connect_network_socket (Lisp_Object proc,
> > Lisp_Object addrinfos,
> >    /* Do this in case we never enter the while-loop below.  */
> >    s = -1;
> >
> > +  record_unwind_protect_nothing ();
> > +  count1 = SPECPDL_INDEX ();
> 
> Since we assume a C99 compiler now, you could just do
> 
>     ptrdiff_t count1 = SPECPDL_INDEX ();
> 
> without having the UNINIT thing.  Also, since free is harmless on a NULL
> pointer, you could just record an unwind protect at the top once,
> without having the nothing state, I think.

Thanks for the comments.  With C99, I would probably gather related
things like:

  struct sockaddr *sa = NULL;
  ptrdiff_t count = SPECPDL_INDEX ();
  record_unwind_protect_nothing ();
	:
  while (!NILP (addrinfos))
    {
	:
      sa = xrealloc (sa, addrlen);
      set_unwind_protect_ptr (count, xfree, sa);
	:
    }
	:
  unbind_to (count, Qnil);

This looks much more idiomatic.  We need to update specbinding
according to (potential) change of the value of `sa' by xrealloc call.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp
   
diff --git a/src/process.c b/src/process.c
index 676f38446e..b0a327229c 100644
--- a/src/process.c
+++ b/src/process.c
@@ -3321,11 +3321,9 @@ static void
 connect_network_socket (Lisp_Object proc, Lisp_Object addrinfos,
                         Lisp_Object use_external_socket_p)
 {
-  ptrdiff_t count = SPECPDL_INDEX ();
   int s = -1, outch, inch;
   int xerrno = 0;
   int family;
-  struct sockaddr *sa = NULL;
   int ret;
   ptrdiff_t addrlen;
   struct Lisp_Process *p = XPROCESS (proc);
@@ -3344,6 +3342,11 @@ connect_network_socket (Lisp_Object proc, Lisp_Object addrinfos,
   /* Do this in case we never enter the while-loop below.  */
   s = -1;
 
+  struct sockaddr *sa = NULL;
+  ptrdiff_t count = SPECPDL_INDEX ();
+  record_unwind_protect_nothing ();
+  ptrdiff_t count1 = SPECPDL_INDEX ();
+
   while (!NILP (addrinfos))
     {
       Lisp_Object addrinfo = XCAR (addrinfos);
@@ -3356,9 +3359,8 @@ connect_network_socket (Lisp_Object proc, Lisp_Object addrinfos,
 #endif
 
       addrlen = get_lisp_to_sockaddr_size (ip_address, &family);
-      if (sa)
-	free (sa);
-      sa = xmalloc (addrlen);
+      sa = xrealloc (sa, addrlen);
+      set_unwind_protect_ptr (count, xfree, sa);
       conv_lisp_to_sockaddr (family, ip_address, sa, addrlen);
 
       s = socket_to_use;
@@ -3520,7 +3522,7 @@ connect_network_socket (Lisp_Object proc, Lisp_Object addrinfos,
 #endif /* !WINDOWSNT */
 
       /* Discard the unwind protect closing S.  */
-      specpdl_ptr = specpdl + count;
+      specpdl_ptr = specpdl + count1;
       emacs_close (s);
       s = -1;
       if (0 <= socket_to_use)
@@ -3591,6 +3593,7 @@ connect_network_socket (Lisp_Object proc, Lisp_Object addrinfos,
 	  Lisp_Object data = get_file_errno_data (err, contact, xerrno);
 
 	  pset_status (p, list2 (Fcar (data), Fcdr (data)));
+	  unbind_to (count, Qnil);
 	  return;
 	}
 
@@ -3610,7 +3613,7 @@ connect_network_socket (Lisp_Object proc, Lisp_Object addrinfos,
   p->outfd = outch;
 
   /* Discard the unwind protect for closing S, if any.  */
-  specpdl_ptr = specpdl + count;
+  specpdl_ptr = specpdl + count1;
 
   if (p->is_server && p->socktype != SOCK_DGRAM)
     pset_status (p, Qlisten);
@@ -3671,6 +3674,7 @@ connect_network_socket (Lisp_Object proc, Lisp_Object addrinfos,
     }
 #endif
 
+  unbind_to (count, Qnil);
 }
 
 /* Create a network stream/datagram client/server process.  Treated





^ permalink raw reply related	[flat|nested] 8+ messages in thread

* bug#32604: 26.1.50; memory leak in connect_network_socket
  2018-09-05 23:50       ` YAMAMOTO Mitsuharu
@ 2018-09-06  0:04         ` Noam Postavsky
  2018-09-06 23:41           ` YAMAMOTO Mitsuharu
  0 siblings, 1 reply; 8+ messages in thread
From: Noam Postavsky @ 2018-09-06  0:04 UTC (permalink / raw)
  To: YAMAMOTO Mitsuharu; +Cc: 32604

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> We need to update specbinding according to (potential) change of the
> value of `sa' by xrealloc call.

Yes, you're right.  I was confused and somehow dreamed up an extra level
of indirection in the unwind_protect mechanism.





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#32604: 26.1.50; memory leak in connect_network_socket
  2018-09-06  0:04         ` Noam Postavsky
@ 2018-09-06 23:41           ` YAMAMOTO Mitsuharu
  0 siblings, 0 replies; 8+ messages in thread
From: YAMAMOTO Mitsuharu @ 2018-09-06 23:41 UTC (permalink / raw)
  To: 32604-done

On Thu, 06 Sep 2018 09:04:27 +0900,
Noam Postavsky wrote:

> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
> 
> > We need to update specbinding according to (potential) change of the
> > value of `sa' by xrealloc call.
> 
> Yes, you're right.  I was confused and somehow dreamed up an extra level
> of indirection in the unwind_protect mechanism.

Installed to the emacs-26 branch.  Closing.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp





^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2018-09-06 23:41 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-09-01  5:38 bug#32604: 26.1.50; memory leak in connect_network_socket YAMAMOTO Mitsuharu
2018-09-01  5:46 ` YAMAMOTO Mitsuharu
2018-09-02 17:55 ` Noam Postavsky
2018-09-03  6:02   ` mituharu
2018-09-04 23:19     ` Noam Postavsky
2018-09-05 23:50       ` YAMAMOTO Mitsuharu
2018-09-06  0:04         ` Noam Postavsky
2018-09-06 23:41           ` YAMAMOTO Mitsuharu

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).