bug#19175: 24.4; make-frame-on-display fails if emacs started with -nw

bug#19175: 24.4; make-frame-on-display fails if emacs started with -nw

[Mario Becroft]

emacs -nw
M-x make-frame-on-display RET
When prompted: myhost:0 RET

Expected result:

A new X11 frame is created on the specified X11 display 'myhost:0'

Actual result:

In minibuffer, the following message appears:

Display myhost:0 can't be opened

Note:

DISPLAY=myhost:0 emacs

works fine, and make-frame-on-display works. It's only when starting
emacs with -nw (or, more importantly, --daemon) that
make-frame-on-display subsequently fails.

This is *not* a simple X authorization problem or anything like that.

The strace output from the point where emacs connects to the X server to
when it closes the connection, without having read or written any data,
follows (actual IP address of target X server host elided and replaced
with 192.168.1.2):

----
socket(PF_INET, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_TCP) = 10
setsockopt(10, SOL_TCP, TCP_NODELAY, [1], 4) = 0
setsockopt(10, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
connect(10, {sa_family=AF_INET, sin_port=htons(6000), sin_addr=inet_addr("192.168.1.2")}, 16) = ? ERESTARTSYS (To be restarted)
--- SIGIO (I/O possible) @ 0 (0) ---
rt_sigreturn(0x1d)                      = -1 EINTR (Interrupted system call)
close(10)                               = 0
----




In GNU Emacs 24.4.1 (x86_64-unknown-linux-gnu, X toolkit)
 of 2014-11-25 on ak2
Configured using:
 `configure --without-toolkit-scroll-bars --with-x
 --with-x-toolkit=lucid --without-xft'

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

Major mode: Lisp Interaction

Minor modes in effect:
  rcirc-track-minor-mode: t
  show-paren-mode: t
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
SPC L i n u x SPC d e s k t o p SPC s y s t e m , SPC 
j u s t SPC s a y : RET D I S P L A Y = : 0 SPC e m 
a c s SPC - n w RET M - x SPC m a k e - f r a m e - 
o n - d i s p l a y RET W h e n SPC p r o m p t e d 
SPC e n t e r : SPC : 0 RET I f SPC a SPC n e w SPC 
f r a m e SPC a p p e a r s , SPC t h e SPC n i t SPC 
i DEL DEL DEL DEL DEL DEL n SPC i t SPC i s SPC w o 
r k i n g RET I f SPC t h e SPC t e x t SPC ' D i s 
p l a y SPC : 0 SPC c a n ' t SPC b e SPC o p e n e 
d ' SPC a p p e a r s SPC i n SPC t h e SPC m i n i 
b u f f e r , SPC t h e n SPC t h e SPC b u g ESC b 
ESC b y o u SPC h a v e SPC RET ESC [ > 0 ; 2 4 2 ; 
0 c ESC ] 1 1 ; r g b : f f f f / f f f f / f f f f 
ESC \ ESC x r e p o TAB r t TAB RET

Recent messages:
When done with this frame, type C-x 5 0
x-initialize-window-system: Display 10.87.0.1:0 can't be opened
x-initialize-window-system: Display 10.89.6.1:0 can't be opened [2 times]
Connecting to chat.freenode.net...done
Quit
Making completion list...
Rcirc-Track minor mode disabled
Rcirc-Track minor mode enabled
When done with this frame, type C-x 5 0
Making completion list...

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message format-spec rfc822 mml mml-sec
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mail-utils help-mode
easymenu disp-table network-stream auth-source eieio byte-opt bytecomp
byte-compile cconv eieio-core gnus-util mm-util help-fns mail-prsvr
password-cache starttls tls rcirc ring xterm server jabber-autoloads
package epg-config escreen time-date paren cus-start cus-load tooltip
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer 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 make-network-process
gfilenotify dynamic-setting x-toolkit x multi-tty emacs)

Memory information:
((conses 16 144895 13629)
 (symbols 48 21822 0)
 (miscs 40 256 529)
 (strings 32 22112 4517)
 (string-bytes 1 584096)
 (vectors 16 11221)
 (vector-slots 8 410639 4818)
 (floats 8 80 297)
 (intervals 56 4036 233)
 (buffers 960 26)
 (heap 1024 23508 585))

bug#19175: Further information

[Mario Becroft]

The functionality described in this bug report was working in emacs
24.3, it is only since upgrading from 24.3 to 24.4.1 that the bug has
appeared.

-- 
Mario Becroft <mb@becroft.co.nz>
p: +64-9-974-9244 m: +64-21-038-5178

bug#19175: 24.4; make-frame-on-display fails if emacs started with -nw

[Jan D.]

Hi.

Does

M-x make-frame-on-display RET
When prompted: :0 RET

work (note, just :0 not myhost:0)?

If it does, then it is likely your X server that has changed to not accept TCP/IP connections.

	Jan D.


> 25 nov 2014 kl. 05:28 skrev Mario Becroft <mb@becroft.co.nz>:
> 
> 
> emacs -nw
> M-x make-frame-on-display RET
> When prompted: myhost:0 RET
> 
> Expected result:
> 
> A new X11 frame is created on the specified X11 display 'myhost:0'
> 
> Actual result:
> 
> In minibuffer, the following message appears:
> 
> Display myhost:0 can't be opened
> 
> Note:
> 
> DISPLAY=myhost:0 emacs
> 
> works fine, and make-frame-on-display works. It's only when starting
> emacs with -nw (or, more importantly, --daemon) that
> make-frame-on-display subsequently fails.
> 
> This is *not* a simple X authorization problem or anything like that.
> 
> The strace output from the point where emacs connects to the X server to
> when it closes the connection, without having read or written any data,
> follows (actual IP address of target X server host elided and replaced
> with 192.168.1.2):
> 
> ----
> socket(PF_INET, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_TCP) = 10
> setsockopt(10, SOL_TCP, TCP_NODELAY, [1], 4) = 0
> setsockopt(10, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
> connect(10, {sa_family=AF_INET, sin_port=htons(6000), sin_addr=inet_addr("192.168.1.2")}, 16) = ? ERESTARTSYS (To be restarted)
> --- SIGIO (I/O possible) @ 0 (0) ---
> rt_sigreturn(0x1d)                      = -1 EINTR (Interrupted system call)
> close(10)                               = 0
> ----
> 
> 
> 
> 
> In GNU Emacs 24.4.1 (x86_64-unknown-linux-gnu, X toolkit)
> of 2014-11-25 on ak2
> Configured using:
> `configure --without-toolkit-scroll-bars --with-x
> --with-x-toolkit=lucid --without-xft'
> 
> Important settings:
>  value of $LANG: en_US.UTF-8
>  locale-coding-system: utf-8-unix
> 
> Major mode: Lisp Interaction
> 
> Minor modes in effect:
>  rcirc-track-minor-mode: t
>  show-paren-mode: t
>  tooltip-mode: t
>  electric-indent-mode: t
>  mouse-wheel-mode: t
>  file-name-shadow-mode: t
>  global-font-lock-mode: t
>  font-lock-mode: t
>  auto-composition-mode: t
>  auto-encryption-mode: t
>  auto-compression-mode: t
>  line-number-mode: t
>  transient-mark-mode: t
> 
> Recent input:
> SPC L i n u x SPC d e s k t o p SPC s y s t e m , SPC 
> j u s t SPC s a y : RET D I S P L A Y = : 0 SPC e m 
> a c s SPC - n w RET M - x SPC m a k e - f r a m e - 
> o n - d i s p l a y RET W h e n SPC p r o m p t e d 
> SPC e n t e r : SPC : 0 RET I f SPC a SPC n e w SPC 
> f r a m e SPC a p p e a r s , SPC t h e SPC n i t SPC 
> i DEL DEL DEL DEL DEL DEL n SPC i t SPC i s SPC w o 
> r k i n g RET I f SPC t h e SPC t e x t SPC ' D i s 
> p l a y SPC : 0 SPC c a n ' t SPC b e SPC o p e n e 
> d ' SPC a p p e a r s SPC i n SPC t h e SPC m i n i 
> b u f f e r , SPC t h e n SPC t h e SPC b u g ESC b 
> ESC b y o u SPC h a v e SPC RET ESC [ > 0 ; 2 4 2 ; 
> 0 c ESC ] 1 1 ; r g b : f f f f / f f f f / f f f f 
> ESC \ ESC x r e p o TAB r t TAB RET
> 
> Recent messages:
> When done with this frame, type C-x 5 0
> x-initialize-window-system: Display 10.87.0.1:0 can't be opened
> x-initialize-window-system: Display 10.89.6.1:0 can't be opened [2 times]
> Connecting to chat.freenode.net...done
> Quit
> Making completion list...
> Rcirc-Track minor mode disabled
> Rcirc-Track minor mode enabled
> When done with this frame, type C-x 5 0
> Making completion list...
> 
> Load-path shadows:
> None found.
> 
> Features:
> (shadow sort mail-extr emacsbug message format-spec rfc822 mml mml-sec
> mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
> mailheader sendmail rfc2047 rfc2045 ietf-drums mail-utils help-mode
> easymenu disp-table network-stream auth-source eieio byte-opt bytecomp
> byte-compile cconv eieio-core gnus-util mm-util help-fns mail-prsvr
> password-cache starttls tls rcirc ring xterm server jabber-autoloads
> package epg-config escreen time-date paren cus-start cus-load tooltip
> electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd
> tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
> lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
> scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
> georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
> korean japanese hebrew greek romanian slovak czech european ethiopic
> indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
> abbrev minibuffer 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 make-network-process
> gfilenotify dynamic-setting x-toolkit x multi-tty emacs)
> 
> Memory information:
> ((conses 16 144895 13629)
> (symbols 48 21822 0)
> (miscs 40 256 529)
> (strings 32 22112 4517)
> (string-bytes 1 584096)
> (vectors 16 11221)
> (vector-slots 8 410639 4818)
> (floats 8 80 297)
> (intervals 56 4036 233)
> (buffers 960 26)
> (heap 1024 23508 585))
> 
> 

bug#19175: 24.4; make-frame-on-display fails if emacs started with -nw

[Mario Becroft]

"Jan D." <jan.h.d@swipnet.se> writes:

> Hi.
>
> Does
>
> M-x make-frame-on-display RET
> When prompted: :0 RET
>
> work (note, just :0 not myhost:0)?
>
> If it does, then it is likely your X server that has changed to not
> accept TCP/IP connections.
>
> 	Jan D.

Thanks for your response. To clarify, my X server is working fine and
accepting TCP connections, as demonstrated by the fact that emacs
started without the -nw option, with the same display specification,
works correctly. The problem is with emacs when started with the -nw or
--daemon options, and then later using make-frame-on-display. This
problem first appeared in a recent version of emacs, I think around
version 24. From memory, version 23 was definitely working, but I'm not
sure whether earlier versions of 24 were working.

I can't actually try using a Unix domain socket connection as you
suggest in my environment, since the emacs process and the X server are
on separate hosts. If it would help, I could configure a test host with
both emacs and an X server, and test whether the bug also occurs with
Unix domain X connections.

-- 
Mario Becroft <mb@becroft.co.nz>       t: @MarioBecroft
p: +64-9-974-9244  m: +64-21-038-5178  w: http://www.becroft.co.nz/

bug#19175: 24.4; make-frame-on-display fails if emacs started with -nw

[Glenn Morris]

Mario Becroft wrote:

> --daemon options, and then later using make-frame-on-display. This
> problem first appeared in a recent version of emacs, I think around
> version 24. From memory, version 23 was definitely working, but I'm not
> sure whether earlier versions of 24 were working.

But in http://debbugs.gnu.org/19175#8 you said that it worked fine in 24.3?

bug#19175: 24.4; make-frame-on-display fails if emacs started with -nw

[Mario Becroft]

Glenn Morris <rgm@gnu.org> writes:

> But in http://debbugs.gnu.org/19175#8 you said that it worked fine in 24.3?

In that case it was working in 24.3. I couldn't remember the exact
version where it broke off the top of my head.

-- 
Mario Becroft <mb@becroft.co.nz>       t: @MarioBecroft
p: +64-9-974-9244  m: +64-21-038-5178  w: http://www.becroft.co.nz/

bug#19175: 24.4; make-frame-on-display fails if emacs started with -nw

[Glenn Morris]

I checked and can confirm that while

emacs -Q           # starts a graphical Emacs
M-x make-frame-on-display RET remote.host:0 RET

works fine, the same thing fails as described from `emacs -Q -nw'.

However, I cannot find any version of Emacs in which the latter does work.
It fails in all the 24 and 22 series.
(23.x infloops when started with -nw, due to some glib incompatibility
IIRC, and I can't be bothered to recompile it now.)

bug#19175: 24.4; make-frame-on-display fails if emacs started with -nw

[Mario Becroft]

Glenn Morris <rgm@gnu.org> writes:

> I checked and can confirm that while
>
> emacs -Q           # starts a graphical Emacs
> M-x make-frame-on-display RET remote.host:0 RET
>
> works fine, the same thing fails as described from `emacs -Q -nw'.
>
> However, I cannot find any version of Emacs in which the latter does work.
> It fails in all the 24 and 22 series.
> (23.x infloops when started with -nw, due to some glib incompatibility
> IIRC, and I can't be bothered to recompile it now.)

Thanks for your input Glenn. I can confirm that on my system, it
certainly did work at least with emacs 23 and possibly earlier versions
of 24.

Perhaps it depends on the configuration, such as which toolkit is used
etc. I compile mine with X, but without external toolkits. In this case,
my configure command was as follows:

./configure --without-toolkit-scroll-bars --with-x --with-x-toolkit=lucid --without-xft

-- 
Mario Becroft <mb@becroft.co.nz>       t: @MarioBecroft
p: +64-9-974-9244  m: +64-21-038-5178  w: http://www.becroft.co.nz/

bug#19175: 24.4; make-frame-on-display fails if emacs started with -nw

[Jan D.]

Hi.

> 29 mar 2015 kl. 05:42 skrev Mario Becroft <mb@becroft.co.nz>:
> 
> Perhaps it depends on the configuration, such as which toolkit is used
> etc. I compile mine with X, but without external toolkits. In this case,
> my configure command was as follows:
> 
> ./configure --without-toolkit-scroll-bars --with-x --with-x-toolkit=lucid --without-xft

No, it is a signal race.  Apparently XOpenDisplay does not retry when interrupted by a signal, SIGIO in this case.
Blocking SIGIO at the appropriate locations fixes it.

Is the fix too late for the 24-branch?

	Jan D.

bug#19175: 24.4; make-frame-on-display fails if emacs started with -nw

[Mario Becroft]

"Jan D." <jan.h.d@swipnet.se> writes:

> Hi.
>
>> 29 mar 2015 kl. 05:42 skrev Mario Becroft <mb@becroft.co.nz>:
>> 
>> Perhaps it depends on the configuration, such as which toolkit is used
>> etc. I compile mine with X, but without external toolkits. In this case,
>> my configure command was as follows:
>> 
>> ./configure --without-toolkit-scroll-bars --with-x
>> --with-x-toolkit=lucid --without-xft
>
> No, it is a signal race.  Apparently XOpenDisplay does not retry when
> interrupted by a signal, SIGIO in this case.
> Blocking SIGIO at the appropriate locations fixes it.
>
> Is the fix too late for the 24-branch?

I wasn't implying knowledge about the cause of the problem, which I have
not investigated myself, only additional information in case it is
relevant. It would be fantastic to see a fix.

Then there are other X-related bugs I have reported, but if the
connection to the server can at least be made, this would be a step
forward.

-- 
Mario Becroft <mb@becroft.co.nz>       t: @MarioBecroft
p: +64-9-974-9244  m: +64-21-038-5178  w: http://www.becroft.co.nz/

bug#19175: 24.4; make-frame-on-display fails if emacs started with -nw

[Eli Zaretskii]

> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Sun, 29 Mar 2015 10:45:16 +0200
> Cc: 19175@debbugs.gnu.org
> 
> No, it is a signal race.  Apparently XOpenDisplay does not retry when interrupted by a signal, SIGIO in this case.
> Blocking SIGIO at the appropriate locations fixes it.
> 
> Is the fix too late for the 24-branch?

Can you show the diffs that fix this?

Thanks.

bug#19175: 24.4; make-frame-on-display fails if emacs started with -nw

[Jan Djärv]

Den 2015-03-29 17:01, Eli Zaretskii skrev:
>> From: "Jan D." <jan.h.d@swipnet.se>
>> Date: Sun, 29 Mar 2015 10:45:16 +0200
>> Cc: 19175@debbugs.gnu.org
>>
>> No, it is a signal race.  Apparently XOpenDisplay does not retry when interrupted by a signal, SIGIO in this case.
>> Blocking SIGIO at the appropriate locations fixes it.
>>
>> Is the fix too late for the 24-branch?
>
> Can you show the diffs that fix this?
>
> Thanks.
>

index fedaa0f..1f48262 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -167,7 +167,9 @@ xg_display_open (char *display_name, Display **dpy)
  {
    GdkDisplay *gdpy;

+  unrequest_sigio ();
    gdpy = gdk_display_open (display_name);
+  request_sigio ();
    if (!gdpy_def && gdpy)
      {
        gdpy_def = gdpy;
diff --git a/src/xterm.c b/src/xterm.c
index 4ca1e13..8284ed9 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -9719,7 +9719,10 @@ get_bits_and_offset (unsigned long mask, int *bits, int 
*offset)
  bool
  x_display_ok (const char *display)
  {
-  Display *dpy = XOpenDisplay (display);
+  Display *dpy;
+  unrequest_sigio ();
+  dpy = XOpenDisplay (display);
+  request_sigio ();
    return dpy ? (XCloseDisplay (dpy), 1) : 0;
  }

@@ -9811,7 +9814,9 @@ x_term_init (Lisp_Object display_name, char *xrm_option, 
char *resource_name)

          /* gtk_init does set_locale.  Fix locale before and after.  */
          fixup_locale ();
+        unrequest_sigio ();
          gtk_init (&argc, &argv2);
+        request_sigio ();
          fixup_locale ();

          g_log_remove_handler ("GLib", id);
@@ -9861,10 +9866,12 @@ x_term_init (Lisp_Object display_name, char 
*xrm_option, char *resource_name)
         argv[argc++] = xrm_option;
        }
      turn_on_atimers (0);
+    unrequest_sigio ();
      dpy = XtOpenDisplay (Xt_app_con, SSDATA (display_name),
                          resource_name, EMACS_CLASS,
                          emacs_options, XtNumber (emacs_options),
                          &argc, argv);
+    request_sigio ();
      turn_on_atimers (1);

  #ifdef HAVE_X11XTR6
@@ -9875,7 +9882,9 @@ x_term_init (Lisp_Object display_name, char *xrm_option, 
char *resource_name)

  #else /* not USE_X_TOOLKIT */
    XSetLocaleModifiers ("");
+  unrequest_sigio ();
    dpy = XOpenDisplay (SSDATA (display_name));
+  request_sigio ();
  #endif /* not USE_X_TOOLKIT */
  #endif /* not USE_GTK*/

	Jan D.

bug#19175: 24.4; make-frame-on-display fails if emacs started with -nw

[Eli Zaretskii]

> Date: Sun, 29 Mar 2015 19:09:48 +0200
> From: Jan Djärv <jan.h.d@swipnet.se>
> CC: mb@becroft.co.nz, 19175@debbugs.gnu.org
> 
> index fedaa0f..1f48262 100644
> --- a/src/gtkutil.c
> +++ b/src/gtkutil.c
> @@ -167,7 +167,9 @@ xg_display_open (char *display_name, Display **dpy)
>   {
>     GdkDisplay *gdpy;
> 
> +  unrequest_sigio ();
>     gdpy = gdk_display_open (display_name);
> +  request_sigio ();
>     if (!gdpy_def && gdpy)
>       {
>         gdpy_def = gdpy;
> diff --git a/src/xterm.c b/src/xterm.c
> index 4ca1e13..8284ed9 100644
> --- a/src/xterm.c
> +++ b/src/xterm.c
> @@ -9719,7 +9719,10 @@ get_bits_and_offset (unsigned long mask, int *bits, int 
> *offset)
>   bool
>   x_display_ok (const char *display)
>   {
> -  Display *dpy = XOpenDisplay (display);
> +  Display *dpy;
> +  unrequest_sigio ();
> +  dpy = XOpenDisplay (display);
> +  request_sigio ();
>     return dpy ? (XCloseDisplay (dpy), 1) : 0;
>   }
> 
> @@ -9811,7 +9814,9 @@ x_term_init (Lisp_Object display_name, char *xrm_option, 
> char *resource_name)
> 
>           /* gtk_init does set_locale.  Fix locale before and after.  */
>           fixup_locale ();
> +        unrequest_sigio ();
>           gtk_init (&argc, &argv2);
> +        request_sigio ();
>           fixup_locale ();
> 
>           g_log_remove_handler ("GLib", id);
> @@ -9861,10 +9866,12 @@ x_term_init (Lisp_Object display_name, char 
> *xrm_option, char *resource_name)
>          argv[argc++] = xrm_option;
>         }
>       turn_on_atimers (0);
> +    unrequest_sigio ();
>       dpy = XtOpenDisplay (Xt_app_con, SSDATA (display_name),
>                           resource_name, EMACS_CLASS,
>                           emacs_options, XtNumber (emacs_options),
>                           &argc, argv);
> +    request_sigio ();
>       turn_on_atimers (1);
> 
>   #ifdef HAVE_X11XTR6
> @@ -9875,7 +9882,9 @@ x_term_init (Lisp_Object display_name, char *xrm_option, 
> char *resource_name)
> 
>   #else /* not USE_X_TOOLKIT */
>     XSetLocaleModifiers ("");
> +  unrequest_sigio ();
>     dpy = XOpenDisplay (SSDATA (display_name));
> +  request_sigio ();
>   #endif /* not USE_X_TOOLKIT */
>   #endif /* not USE_GTK*/

Thanks, this looks safe enough to me.  Just add some comments to
explain the need.

I hope Nicolas won't mind preparing a new tarball for the release.

bug#19175: 24.4; make-frame-on-display fails if emacs started with -nw

[Jan D.]

Fixed in the emacs-24 branch.

	Jan D.

> 29 mar 2015 kl. 19:20 skrev Eli Zaretskii <eliz@gnu.org>:
> 
>> Date: Sun, 29 Mar 2015 19:09:48 +0200
>> From: Jan Djärv <jan.h.d@swipnet.se>
>> CC: mb@becroft.co.nz, 19175@debbugs.gnu.org
>> 
>> index fedaa0f..1f48262 100644
>> --- a/src/gtkutil.c
>> +++ b/src/gtkutil.c
>> @@ -167,7 +167,9 @@ xg_display_open (char *display_name, Display **dpy)
>>  {
>>    GdkDisplay *gdpy;
>> 
>> +  unrequest_sigio ();
>>    gdpy = gdk_display_open (display_name);
>> +  request_sigio ();
>>    if (!gdpy_def && gdpy)
>>      {
>>        gdpy_def = gdpy;
>> diff --git a/src/xterm.c b/src/xterm.c
>> index 4ca1e13..8284ed9 100644
>> --- a/src/xterm.c
>> +++ b/src/xterm.c
>> @@ -9719,7 +9719,10 @@ get_bits_and_offset (unsigned long mask, int *bits, int 
>> *offset)
>>  bool
>>  x_display_ok (const char *display)
>>  {
>> -  Display *dpy = XOpenDisplay (display);
>> +  Display *dpy;
>> +  unrequest_sigio ();
>> +  dpy = XOpenDisplay (display);
>> +  request_sigio ();
>>    return dpy ? (XCloseDisplay (dpy), 1) : 0;
>>  }
>> 
>> @@ -9811,7 +9814,9 @@ x_term_init (Lisp_Object display_name, char *xrm_option, 
>> char *resource_name)
>> 
>>          /* gtk_init does set_locale.  Fix locale before and after.  */
>>          fixup_locale ();
>> +        unrequest_sigio ();
>>          gtk_init (&argc, &argv2);
>> +        request_sigio ();
>>          fixup_locale ();
>> 
>>          g_log_remove_handler ("GLib", id);
>> @@ -9861,10 +9866,12 @@ x_term_init (Lisp_Object display_name, char 
>> *xrm_option, char *resource_name)
>>         argv[argc++] = xrm_option;
>>        }
>>      turn_on_atimers (0);
>> +    unrequest_sigio ();
>>      dpy = XtOpenDisplay (Xt_app_con, SSDATA (display_name),
>>                          resource_name, EMACS_CLASS,
>>                          emacs_options, XtNumber (emacs_options),
>>                          &argc, argv);
>> +    request_sigio ();
>>      turn_on_atimers (1);
>> 
>>  #ifdef HAVE_X11XTR6
>> @@ -9875,7 +9882,9 @@ x_term_init (Lisp_Object display_name, char *xrm_option, 
>> char *resource_name)
>> 
>>  #else /* not USE_X_TOOLKIT */
>>    XSetLocaleModifiers ("");
>> +  unrequest_sigio ();
>>    dpy = XOpenDisplay (SSDATA (display_name));
>> +  request_sigio ();
>>  #endif /* not USE_X_TOOLKIT */
>>  #endif /* not USE_GTK*/
> 
> Thanks, this looks safe enough to me.  Just add some comments to
> explain the need.
> 
> I hope Nicolas won't mind preparing a new tarball for the release.

bug#19175: 24.4; make-frame-on-display fails if emacs started with -nw

[Stefan Monnier]

> Is the fix too late for the 24-branch?

Yes, emacs-24 is frozen now.


        Stefan

bug#19175: 24.4; make-frame-on-display fails if emacs started with -nw

[Jan D.]

> 29 mar 2015 kl. 23:17 skrev Stefan Monnier <monnier@iro.umontreal.ca>:
> 
>> Is the fix too late for the 24-branch?
> 
> Yes, emacs-24 is frozen now.
> 

Hmm, I checked in that change.  But the changelog (now out of order) suggests 24.5 has been released.
But there is no tag yet.  How shall we handle this situation?

	Jan D.

bug#19175: 24.4; make-frame-on-display fails if emacs started with -nw

[Stefan Monnier]

>>> Is the fix too late for the 24-branch?
>> Yes, emacs-24 is frozen now.
> Hmm, I checked in that change.  But the changelog (now out of order)
> suggests 24.5 has been released.
> But there is no tag yet.  How shall we handle this situation?

I don't think this fix is important enough to delay the release.
So I think the way to fix this is for Nicolas to just ignore this commit
(i.e. he simply shouldn't do "git pull" or anything equivalent).
And he should indeed add the tag (and tweak the release instructions so
as to try and make sure we don't forget this tag any more).


        Stefan

bug#19175: 24.4; make-frame-on-display fails if emacs started with -nw

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 30 Mar 2015 09:58:38 -0400
> Cc: Nicolas Petton <nicolas@petton.fr>, 19175@debbugs.gnu.org,
> 	Mario Becroft <mb@becroft.co.nz>
> 
> >>> Is the fix too late for the 24-branch?
> >> Yes, emacs-24 is frozen now.
> > Hmm, I checked in that change.  But the changelog (now out of order)
> > suggests 24.5 has been released.
> > But there is no tag yet.  How shall we handle this situation?
> 
> I don't think this fix is important enough to delay the release.

I obviously think differently.  Fixing the ChangeLog is easy, if
that's the only problem: just swap the entries.

bug#19175: 24.4; make-frame-on-display fails if emacs started with -nw

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 30 Mar 2015 09:58:38 -0400
> Cc: Nicolas Petton <nicolas@petton.fr>, 19175@debbugs.gnu.org,
> 	Mario Becroft <mb@becroft.co.nz>
> 
> I don't think this fix is important enough to delay the release.

Btw, there's no need to delay the release, just redo the tarball.

bug#19175: 24.4; make-frame-on-display fails if emacs started with -nw

[Stefan Monnier]

>> I don't think this fix is important enough to delay the release.
> I obviously think differently.

How old is this bug?  IIUC it's pretty old, so there's no hurry to
fix it in 24.5 rather than in Emacs-25.  It's not fixing a regression.

> Fixing the ChangeLog is easy, if
> that's the only problem: just swap the entries.

No, the problem is delaying the release by having another RC candidate.


        Stefan

bug#19175: 24.4; make-frame-on-display fails if emacs started with -nw

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: jan.h.d@swipnet.se,  nicolas@petton.fr,  19175@debbugs.gnu.org,  mb@becroft.co.nz
> Date: Mon, 30 Mar 2015 16:51:22 -0400
> 
> >> I don't think this fix is important enough to delay the release.
> > I obviously think differently.
> 
> How old is this bug?  IIUC it's pretty old, so there's no hurry to
> fix it in 24.5 rather than in Emacs-25.  It's not fixing a regression.

It is still a bad problem, and could very well raise its ugly head in
other, more important situations.

> > Fixing the ChangeLog is easy, if
> > that's the only problem: just swap the entries.
> 
> No, the problem is delaying the release by having another RC candidate.

There's no need: we are making a simple change that doesn't require
another RC, IMO.

bug#19175: 24.4; make-frame-on-display fails if emacs started with -nw

[Stefan Monnier]

>> How old is this bug?  IIUC it's pretty old, so there's no hurry to
>> fix it in 24.5 rather than in Emacs-25.  It's not fixing a regression.
> It is still a bad problem, and could very well raise its ugly head in
> other, more important situations.

It could, but it hasn't in the last many years that we've lived with it
without anyone noticing, so we can live with it a few more I think.
And the effect of the bug seems rather minor.
IOW the urgency is very low.

>> > Fixing the ChangeLog is easy, if
>> > that's the only problem: just swap the entries.
>> No, the problem is delaying the release by having another RC candidate.
> There's no need: we are making a simple change that doesn't require
> another RC, IMO.

I don't find it simple at all.  E.g. it doesn't seem obviously safe
(e.g. what if the X call ends up making a longjmp and hence skipping the
unblocking of sigio?  Seems highly unlikely, but we do make longjmps in
not-completely-different circumstances (e.g. to avoid killing Emacs when
an X connection dies), so I think that proving such a longjmp can't
happen would require a serious code analysis, i.e. pretty far from
"obviously safe").

Low urgency, non-zero risk, I'm surprised you'd even bother to lobby for
inclusion one day before the actual release.


        Stefan

bug#19175: 24.4; make-frame-on-display fails if emacs started with -nw

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: jan.h.d@swipnet.se,  nicolas@petton.fr,  19175@debbugs.gnu.org,  mb@becroft.co.nz
> Date: Tue, 31 Mar 2015 09:26:58 -0400
> 
> >> How old is this bug?  IIUC it's pretty old, so there's no hurry to
> >> fix it in 24.5 rather than in Emacs-25.  It's not fixing a regression.
> > It is still a bad problem, and could very well raise its ugly head in
> > other, more important situations.
> 
> It could, but it hasn't in the last many years that we've lived with it
> without anyone noticing, so we can live with it a few more I think.
> And the effect of the bug seems rather minor.
> IOW the urgency is very low.

I don't see it as low: subtle, hard to reproduce failures in Xlib
calls could very well bring the whole session down.  That they only
happened when opening a new frame might very well be sheer luck.

IME, the fact that a bug never happened (or, more accurately, was
never reported) before says nothing at all about its probability or
the chance to see it again tomorrow.  These are Poisson processes, and
they are known to be nasty in this regard.

> >> > Fixing the ChangeLog is easy, if
> >> > that's the only problem: just swap the entries.
> >> No, the problem is delaying the release by having another RC candidate.
> > There's no need: we are making a simple change that doesn't require
> > another RC, IMO.
> 
> I don't find it simple at all.  E.g. it doesn't seem obviously safe
> (e.g. what if the X call ends up making a longjmp and hence skipping the
> unblocking of sigio?

If we fear this, it should be a simple manner to see if Xlib does any
longjmp at all.

> Low urgency, non-zero risk, I'm surprised you'd even bother to lobby for
> inclusion one day before the actual release.

That's because I disagree about both the urgency and the risk.  Also,
should it prove to be a problem, immediately releasing 24.6 with that
change reverted is a very simple matter.

So I see no reason not to include this patch in 24.5.  We have nothing
to lose, really.

bug#19175: 24.4; make-frame-on-display fails if emacs started with -nw

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 627 bytes --]


Eli Zaretskii writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Mon, 30 Mar 2015 09:58:38 -0400
>> Cc: Nicolas Petton <nicolas@petton.fr>, 19175@debbugs.gnu.org,
>> 	Mario Becroft <mb@becroft.co.nz>
>> 
>> I don't think this fix is important enough to delay the release.
>
> Btw, there's no need to delay the release, just redo the tarball.

FWIW, it'd be fine with me to do another RC tomorrow and release on
Friday on next Monday.

I don't know if adding this commit in the release tomorrow without
another RC is ok or not.

Cheers,
Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

bug#19175: 24.4; make-frame-on-display fails if emacs started with -nw

[Stefan Monnier]

> IME, the fact that a bug never happened (or, more accurately, was
> never reported) before says nothing at all about its probability or
> the chance to see it again tomorrow.  These are Poisson processes, and
> they are known to be nasty in this regard.

It's no guarantee, but there is actually a very strong correlation
between the past and the future.

> Also, should it prove to be a problem, immediately releasing 24.6 with
> that change reverted is a very simple matter.

This argument cuts both ways.


        Stefan

bug#19175: 24.4; make-frame-on-display fails if emacs started with -nw

[Stefan Monnier]

>> Btw, there's no need to delay the release, just redo the tarball.
> FWIW, it'd be fine with me to do another RC tomorrow and release on
> Friday on next Monday.
> I don't know if adding this commit in the release tomorrow without
> another RC is ok or not.

No, let's just go ahead with the release tomorrow as planned.


        Stefan

bug#19175: 24.4; make-frame-on-display fails if emacs started with -nw

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: jan.h.d@swipnet.se,  nicolas@petton.fr,  19175@debbugs.gnu.org,  mb@becroft.co.nz
> Date: Tue, 31 Mar 2015 17:07:37 -0400
> 
> > IME, the fact that a bug never happened (or, more accurately, was
> > never reported) before says nothing at all about its probability or
> > the chance to see it again tomorrow.  These are Poisson processes, and
> > they are known to be nasty in this regard.
> 
> It's no guarantee, but there is actually a very strong correlation
> between the past and the future.

No, there isn't, not IME.

> > Also, should it prove to be a problem, immediately releasing 24.6 with
> > that change reverted is a very simple matter.
> 
> This argument cuts both ways.

But with my suggestion, the average gain is higher.

bug#19175: 24.4; make-frame-on-display fails if emacs started with -nw

[Stefan Monnier]

>> > Also, should it prove to be a problem, immediately releasing 24.6 with
>> > that change reverted is a very simple matter.
>> This argument cuts both ways.
> But with my suggestion, the average gain is higher.

More importantly, the risk is higher.

If you want to have a 24.6 with that fix, go for it, but it shouldn't be
in 24.5 because it's too late and not important enough.


        Stefan