Re: emacs server with X11 build on OSX

Re: emacs server with X11 build on OSX

[Juanma Barranquero]

(I'm Cc:ing this to bug-gnu-emacs to create a bug report.)

On Mon, Aug 2, 2010 at 17:56, Leo <sdl.web@gmail.com> wrote:

>> (make-network-process :name "server" :server t :family nil :service t
>> :host 'local)

> I have used the following in server-start as workaround:
>
>  (make-network-process :name "server" :server t :family 'ipv4 :service t)

If ":family 'ipv4" works and ":family nil" does not, that surely means
that Emacs is chosing ipv6. Does server.el work with the attached
patch?

I don't know whether that means that your system is set up only for
ipv6, or that it has both ipv6 and ipv4 and make-network-process is
selecting ipv6 for `localhost'. In any case, server.el / emacsclient.c
are not adapted to ipv6, so forcing ipv4 seems right for the moment
being.

    Juanma



=== modified file 'lisp/server.el'
--- lisp/server.el	2010-05-29 23:50:47 +0000
+++ lisp/server.el	2010-08-02 20:16:16 +0000
@@ -564,5 +564,5 @@
 		       ;; The other args depend on the kind of socket used.
 		       (if server-use-tcp
-			   (list :family nil
+			   (list :family 'ipv4
 				 :service t
 				 :host (or server-host 'local)

bug#6781: emacs server with X11 build on OSX

[Leo]

,----
| (make-network-process :name "server" :server t :family 'ipv4 :service t :host 'local).
`----

Fails with backtrace:
,----
| Debugger entered--Lisp error: (error "localhost/0 nodename nor servname provided, or not known")
|   make-network-process(:name "server" :server t :family ipv4 :service t :host local)
|   eval((make-network-process :name "server" :server t :family (quote ipv4) :service t :host (quote local)))
|   eval-last-sexp-1(nil)
|   eval-last-sexp(nil)
|   call-interactively(eval-last-sexp nil nil)
`----

and
,----
| (make-network-process :name "server" :server t :family 'ipv4 :service t :host "localhost")
`----
fails in the same way.

However, the following works:
,----
| (make-network-process :name "server" :server t :family 'ipv4 :service t :host "127.0.0.1")
`----


`ping localhost' in terminal shows:
,----
| leo@Victoria ~$ ping localhost
| PING localhost (127.0.0.1): 56 data bytes
| 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.041 ms
| 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.049 ms
`----

Leo

Re: emacs server with X11 build on OSX

[Ken Raeburn]

On Aug 2, 2010, at 16:22, Juanma Barranquero wrote:

> (I'm Cc:ing this to bug-gnu-emacs to create a bug report.)
> 
> On Mon, Aug 2, 2010 at 17:56, Leo <sdl.web@gmail.com> wrote:
> 
>>> (make-network-process :name "server" :server t :family nil :service t
>>> :host 'local)
> 
>> I have used the following in server-start as workaround:
>> 
>>  (make-network-process :name "server" :server t :family 'ipv4 :service t)
> 
> If ":family 'ipv4" works and ":family nil" does not, that surely means
> that Emacs is chosing ipv6. Does server.el work with the attached
> patch?

There was one more difference, which was that your suggestion included ":host 'local" and his workaround did not.

Using ":host 'local" causes the C code to look up the name "localhost", which may or may not map to IPv4 and/or IPv6 addresses.  (Almost always an IPv4 address of 127.0.0.1; sometimes IPv6 also, and I've occasionally seen it mapped to the local ethernet interface's IPv4 address.)  Not specifying the host at all causes a wildcard address to be used, which would be reachable from other hosts, whereas 127.0.0.1 generally is not.  (Actually, in the version I'm looking at, which isn't quite current, it causes INADDR_ANY to be used, which looks like a bug if the address family is not specifically given as AF_INET.  I'll try to look at that a little closer if I get some time next weekend.)

> I don't know whether that means that your system is set up only for
> ipv6, or that it has both ipv6 and ipv4 and make-network-process is
> selecting ipv6 for `localhost'. In any case, server.el / emacsclient.c
> are not adapted to ipv6, so forcing ipv4 seems right for the moment
> being.

Yes.

Ken

bug#6781: emacs server with X11 build on OSX

[Juanma Barranquero]

On Tue, Aug 3, 2010 at 04:12, Ken Raeburn <raeburn@raeburn.org> wrote:

> Using ":host 'local" causes the C code to look up the name "localhost",
> which may or may not map to IPv4 and/or IPv6 addresses.  (Almost
> always an IPv4 address of 127.0.0.1; sometimes IPv6 also, and I've
> occasionally seen it mapped to the local ethernet interface's IPv4
> address.)  Not specifying the host at all causes a wildcard address to
> be used, which would be reachable from other hosts, whereas
> 127.0.0.1 generally is not.

[Ah, the wonders of TCP.]

I think you're right, because in Leo's examples it works when he
specifically sets "127.0.0.1", so it's clear that Emacs isn't
selecting that address with "localhost" or 'local. I suppose the Right
Thing to do for server.el is to force it to use "127.0.0.1" instead of
'local for the :host argument.

    Juanma


=== modified file 'lisp/server.el'
--- lisp/server.el	2010-01-13 08:35:10 +0000
+++ lisp/server.el	2010-08-03 02:44:17 +0000
@@ -561,7 +561,7 @@
 		       ;; The other args depend on the kind of socket used.
 		       (if server-use-tcp
-			   (list :family nil
+			   (list :family 'ipv4
 				 :service t
-				 :host (or server-host 'local)
+				 :host (or server-host "127.0.0.1") ;; bug#6781
 				 :plist '(:authenticated nil))
 			 (list :family 'local

bug#6781: emacs server with X11 build on OSX

[Leo]

On 2010-08-03 03:47 +0100, Juanma Barranquero wrote:
> I think you're right, because in Leo's examples it works when he
> specifically sets "127.0.0.1", so it's clear that Emacs isn't
> selecting that address with "localhost" or 'local. I suppose the Right
> Thing to do for server.el is to force it to use "127.0.0.1" instead of
> 'local for the :host argument.
>
>     Juanma
[...]

I think this can be the workaround for now while waiting for Ken to look
at the C side for more bugs there. Thank you both.

Could you also simplify (more readable) the loop in server-start like
this:

diff --git a/lisp/server.el b/lisp/server.el
index 1042bee..bd0d62b 100644
--- a/lisp/server.el
+++ b/lisp/server.el
@@ -572,11 +572,11 @@ server or call `M-x server-force-delete' to forcibly disconnect it.")
 	  (when server-use-tcp
 	    (let ((auth-key
 		   (loop
-		      ;; The auth key is a 64-byte string of random chars in the
-		      ;; range `!'..`~'.
-		      for i below 64
-		      collect (+ 33 (random 94)) into auth
-		      finally return (concat auth))))
+		    ;; The auth key is a 64-byte string of random chars in the
+		    ;; range `!'..`~'.
+		    repeat 64
+		    collect (+ 33 (random 94)) into auth
+		    finally return (concat auth))))
 	      (process-put server-process :auth-key auth-key)
 	      (with-temp-file server-file
 		(set-buffer-multibyte nil)

Leo

bug#6781: emacs server with X11 build on OSX

[Juanma Barranquero]

On Tue, Aug 3, 2010 at 07:01, Leo <sdl.web@gmail.com> wrote:

> On 2010-08-03 03:47 +0100, Juanma Barranquero wrote:
>> I suppose the Right
>> Thing to do for server.el is to force it to use "127.0.0.1" instead of
>> 'local for the :host argument.

> I think this can be the workaround for now while waiting for Ken to look
> at the C side for more bugs there. Thank you both.

I meant that server.el should stick to IPv4 and make sure it does so,
not that it was the fix for your problem.

If you ping localhost and it reaches 127.0.0.1, but
(make-network-proces ... :host 'local) does not use that address, it
is obvious there's a bug somewhere...

> Could you also simplify (more readable) the loop in server-start like this:

> -                     for i below 64
> +                   repeat 64

Nice. I wonder why did I miss "repeat".

    Juanma

bug#6781: emacs server with X11 build on OSX

[Andreas Schwab]

Juanma Barranquero <lekktu@gmail.com> writes:

> If you ping localhost and it reaches 127.0.0.1, but

ping probably does not use getaddrinfo, but the older gethostbyname
(which does not properly support IPv6).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#6781: emacs server with X11 build on OSX

[Juanma Barranquero]

On Tue, Aug 3, 2010 at 14:44, Andreas Schwab <schwab@linux-m68k.org> wrote:

> ping probably does not use getaddrinfo, but the older gethostbyname
> (which does not properly support IPv6).

Still a problem, isn't it?

    Juanma

bug#6781: emacs server with X11 build on OSX

[Andreas Schwab]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Tue, Aug 3, 2010 at 14:44, Andreas Schwab <schwab@linux-m68k.org> wrote:
>
>> ping probably does not use getaddrinfo, but the older gethostbyname
>> (which does not properly support IPv6).
>
> Still a problem, isn't it?

gethostbyname works quite different from getaddrinfo.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#6781: emacs server with X11 build on OSX

[Juanma Barranquero]

On Tue, Aug 3, 2010 at 15:01, Andreas Schwab <schwab@linux-m68k.org> wrote:

> gethostbyname works quite different from getaddrinfo.

Still a problem that (make-network-process ... :host 'local) fails.
Something's obviously not right.

    Juanma

bug#6781: emacs server with X11 build on OSX

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 3 Aug 2010 15:03:08 +0200, Juanma Barranquero <lekktu@gmail.com> said:

> On Tue, Aug 3, 2010 at 15:01, Andreas Schwab <schwab@linux-m68k.org>
> wrote:
>> gethostbyname works quite different from getaddrinfo.

> Still a problem that (make-network-process ... :host 'local) fails.
> Something's obviously not right.

I suspect there is a bug in getaddrinfo on Mac OS X 10.6.4.  At least,
the behavior of the following program is incompatible with that on Mac
OS X 10.5.8.

#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netdb.h>

main ()
{
  struct addrinfo hints, *res;
  char *servnames[] = {"0", "1", NULL};
  int error, i;

  memset (&hints, 0, sizeof (hints));
  hints.ai_family = PF_UNSPEC;
  hints.ai_socktype = SOCK_STREAM;
  for (i = 0; i < sizeof (servnames) / sizeof (servnames[0]); i++)
    {
      if (servnames[i])
	printf ("servname = \"%s\":\n", servnames[i]);
      else
	printf ("servname = (null):\n");
      error = getaddrinfo ("localhost", servnames[i], &hints, &res);
      if (error != 0)
	puts (gai_strerror (error));
      else
	{
	  struct addrinfo *r;

	  for (r = res; r; r = r->ai_next)
	    {
	      printf ("family = %d, socktype = %d, protocol = %d\n",
		      r->ai_family, r->ai_socktype, r->ai_protocol);
	    }
	  freeaddrinfo (res);
	}
      puts ("");
    }
}

*** Mac OS X 10.6.4 ***
servname = "0":
nodename nor servname provided, or not known

servname = "1":
family = 30, socktype = 1, protocol = 6
family = 30, socktype = 1, protocol = 6
family = 2, socktype = 1, protocol = 6

servname = (null):
family = 30, socktype = 1, protocol = 6
family = 30, socktype = 1, protocol = 6
family = 2, socktype = 1, protocol = 6


*** Mac OS X 10.5.8 ***
servname = "0":
family = 30, socktype = 1, protocol = 6
family = 30, socktype = 1, protocol = 6
family = 2, socktype = 1, protocol = 6

servname = "1":
family = 30, socktype = 1, protocol = 6
family = 30, socktype = 1, protocol = 6
family = 2, socktype = 1, protocol = 6

servname = (null):
family = 30, socktype = 1, protocol = 6
family = 30, socktype = 1, protocol = 6
family = 2, socktype = 1, protocol = 6


Actually, one can find a major rewrite in getaddrinfo's
implementation.  (Libinfo in
http://opensource.apple.com/release/mac-os-x-1064/ and
http://opensource.apple.com/release/mac-os-x-1058/ )

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

bug#6781: emacs server with X11 build on OSX

[Stefan Monnier]

> -			   (list :family nil
> +			   (list :family 'ipv4

That would make sense if emacsclient.c only supports ipv4.  Not being
up-to-speed on ipv6, I do not know whether that's the case.

> -				 :host (or server-host 'local)
> +				 :host (or server-host "127.0.0.1") ;; bug#6781

We should rather do that in the C code of make-network-process, where
instead of "localhost" we might prefer using "127.0.0.1".


        Stefan

bug#6781: emacs server with X11 build on OSX

[Chong Yidong]

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

> I suspect there is a bug in getaddrinfo on Mac OS X 10.6.4.  At least,
> the behavior of the following program is incompatible with that on Mac
> OS X 10.5.8.

Could you write a PROBLEMS entry about your discovery?

bug#6781: emacs server with X11 build on OSX

[Juanma Barranquero]

On Wed, Aug 4, 2010 at 15:18, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> That would make sense if emacsclient.c only supports ipv4.  Not being
> up-to-speed on ipv6, I do not know whether that's the case.

It is right now, at least because there are a few hardcoded 127.0.0.1.

> We should rather do that in the C code of make-network-process, where
> instead of "localhost" we might prefer using "127.0.0.1".

Wouldn't that run counter to adapting to IPv6?

    Juanma

bug#6781: emacs server with X11 build on OSX

[Stefan Monnier]

>> That would make sense if emacsclient.c only supports ipv4.  Not being
>> up-to-speed on ipv6, I do not know whether that's the case.
> It is right now, at least because there are a few hardcoded 127.0.0.1.

OK.

>> We should rather do that in the C code of make-network-process, where
>> instead of "localhost" we might prefer using "127.0.0.1".
> Wouldn't that run counter to adapting to IPv6?

Could be, but if the workaround is needed for server.el, I can't see why
it would not be needed for other (IPv4) uses of make-network-process.


        Stefan

bug#6781: emacs server with X11 build on OSX

[Juanma Barranquero]

On Mon, Aug 9, 2010 at 13:24, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Could be, but if the workaround is needed for server.el, I can't see why
> it would not be needed for other (IPv4) uses of make-network-process.

You're right, but at the moment we haven't received any other
complain, and it's equally possible that changing it will break
someone's code that works right now.

But, all in all, I agree that if `localhost' can be interpreted as
variably as Ken has pointed out, we shouldn't use it.

    Juanma

bug#6781: emacs server with X11 build on OSX

[Stefan Monnier]

>> Could be, but if the workaround is needed for server.el, I can't see why
>> it would not be needed for other (IPv4) uses of make-network-process.
> You're right, but at the moment we haven't received any other
> complain, and it's equally possible that changing it will break
> someone's code that works right now.

For Emacs-24's code, it's OK because we have a fair bit of time to test it.

> But, all in all, I agree that if `localhost' can be interpreted as
> variably as Ken has pointed out, we shouldn't use it.

Could you make the corresponding change in `trunk'?


        Stefan

bug#6781: emacs server with X11 build on OSX

[Juanma Barranquero]

On Tue, Aug 10, 2010 at 15:31, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Could you make the corresponding change in `trunk'?

Not now. I'm in a hotel, with spotty and not very secure internet
access and a slooooow EeePC; hardly the time to hack Emacs :-(

I'll work on it after Aug, 18 if no one beats me.

    Juanma

bug#6781: emacs server with X11 build on OSX

[Juanma Barranquero]

On Tue, Aug 10, 2010 at 15:31, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
>> But, all in all, I agree that if `localhost' can be interpreted as
>> variably as Ken has pointed out, we shouldn't use it.
>
> Could you make the corresponding change in `trunk'?

OK to this change, then?

    Juanma



2010-09-24  Juanma Barranquero	<lekktu@gmail.com>

	* server.el (server-start): Revert part of 2010-08-08 change.  Using
	address 127.0.0.1 for local host is now done in Fmake_network_process.

2010-09-24  Juanma Barranquero	<lekktu@gmail.com>

	* process.c (Fmake_network_process): When arg :host is 'local,
	use address 127.0.0.1, not name "localhost".  (Bug#6781)


=== modified file 'lisp/server.el'
--- lisp/server.el	2010-08-26 13:46:19 +0000
+++ lisp/server.el	2010-09-24 19:16:01 +0000
@@ -565,7 +565,7 @@
 		       (if server-use-tcp
 			   (list :family 'ipv4  ;; We're not ready for IPv6 yet
 				 :service t
-				 :host (or server-host "127.0.0.1") ;; See bug#6781
+				 :host (or server-host 'local)
 				 :plist '(:authenticated nil))
 			 (list :family 'local
 			       :service server-file

=== modified file 'src/process.c'
--- src/process.c	2010-09-17 15:47:49 +0000
+++ src/process.c	2010-09-24 19:31:13 +0000
@@ -3170,7 +3170,9 @@
   if (!NILP (host))
     {
       if (EQ (host, Qlocal))
-	host = build_string ("localhost");
+	/* Depending on setup, "localhost" may map to different IPv4 and/or
+	   IPv6 addresses, so it's better to be explicit.  (Bug#6781) */
+	host = build_string ("127.0.0.1");
       CHECK_STRING (host);
     }

bug#6781: emacs server with X11 build on OSX

[Stefan Monnier]

>>> But, all in all, I agree that if `localhost' can be interpreted as
>>> variably as Ken has pointed out, we shouldn't use it.
>> Could you make the corresponding change in `trunk'?
> OK to this change, then?

Looks OK, thanks,


        Stefan

bug#6781: emacs server with X11 build on OSX

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 04 Aug 2010 11:25:53 -0400, Chong Yidong <cyd@stupidchicken.com> said:

> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>> I suspect there is a bug in getaddrinfo on Mac OS X 10.6.4.  At
>> least, the behavior of the following program is incompatible with
>> that on Mac OS X 10.5.8.

> Could you write a PROBLEMS entry about your discovery?

I think it is more natural to specify NULL for the unspecified port
case, and it also works as a workaround.

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

=== modified file 'src/process.c'
*** src/process.c	2010-06-03 22:47:35 +0000
--- src/process.c	2010-09-25 03:52:03 +0000
***************
*** 3446,3452 ****
        /* SERVICE can either be a string or int.
  	 Convert to a C string for later use by getaddrinfo.  */
        if (EQ (service, Qt))
! 	portstring = "0";
        else if (INTEGERP (service))
  	{
  	  sprintf (portbuf, "%ld", (long) XINT (service));
--- 3446,3455 ----
        /* SERVICE can either be a string or int.
  	 Convert to a C string for later use by getaddrinfo.  */
        if (EQ (service, Qt))
! 	/* We pass NULL for unspecified port, because some versions of
! 	   Darwin return EAI_NONAME for getaddrinfo ("localhost", "0",
! 	   ...).  */
! 	portstring = NULL;
        else if (INTEGERP (service))
  	{
  	  sprintf (portbuf, "%ld", (long) XINT (service));
***************
*** 3472,3482 ****
  
        ret = getaddrinfo (SDATA (host), portstring, &hints, &res);
        if (ret)
  #ifdef HAVE_GAI_STRERROR
! 	error ("%s/%s %s", SDATA (host), portstring, gai_strerror(ret));
  #else
! 	error ("%s/%s getaddrinfo error %d", SDATA (host), portstring, ret);
  #endif
        immediate_quit = 0;
  
        goto open_socket;
--- 3475,3493 ----
  
        ret = getaddrinfo (SDATA (host), portstring, &hints, &res);
        if (ret)
+ 	{
  #ifdef HAVE_GAI_STRERROR
! 	  if (portstring)
! 	    error ("%s/%s %s", SDATA (host), portstring, gai_strerror(ret));
! 	  else
! 	    error ("%s %s", SDATA (host), gai_strerror(ret));
  #else
! 	  if (portstring)
! 	    error ("%s/%s getaddrinfo error %d", SDATA (host), portstring, ret);
! 	  else
! 	    error ("%s getaddrinfo error %d", SDATA (host), ret);
  #endif
+ 	}
        immediate_quit = 0;
  
        goto open_socket;

bug#6781: emacs server with X11 build on OSX

[Juanma Barranquero]

On Sat, Sep 25, 2010 at 05:57, YAMAMOTO Mitsuharu
<mituharu@math.s.chiba-u.ac.jp> wrote:
>>>>>> On Wed, 04 Aug 2010 11:25:53 -0400, Chong Yidong <cyd@stupidchicken.com> said:
>
>> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>>> I suspect there is a bug in getaddrinfo on Mac OS X 10.6.4.  At
>>> least, the behavior of the following program is incompatible with
>>> that on Mac OS X 10.5.8.
>
>> Could you write a PROBLEMS entry about your discovery?
>
> I think it is more natural to specify NULL for the unspecified port
> case, and it also works as a workaround.

That is another bug. I'm closing this one.

I suggest either commiting your fix, if appropriate, or filing a new
bug report with your patch so it can be discussed.

    Juanma