RE: Emacs - cannot connect to X server

[Matt Muggeridge]

Hi,

Today when I was firing up the patched emacs, I saw the problem once again.
So it seems that your fixes do not entirely address the problem, but
whatever timing window causes the problem, it is much smaller with your
patch.

In summary, I can now say that the problem is much less likely to occur, but
it still exists.  Is there any other data you would like me to gather?

Thanks,
Matt.

>-----Original Message-----
>From: Matt Muggeridge 
>Sent: Tuesday, 2 July 2002 10:17 AM
>To: Matt Muggeridge; 'rms@gnu.org'; Matt.Muggeridge@hp.com
>Cc: bug-gnu-emacs@gnu.org
>Subject: RE: Emacs - cannot connect to X server
>
>
>OK, I have been able to test your code changes and have more 
>confidently demonstrated that it does address the timing 
>problem.  (See test procedure below for details).
>
>I also learnt that starting emacs in the background (by 
>invoking 'emacs&') would most regularly cause the timing 
>problem, whereas starting emacs in the foreground (by invoking 
>'emacs') would rarely cause the timing problem.  Out of habit, 
>I start emacs in the background.
>
>In conclusion, your proposed code changes do in fact address 
>the problem.
>
>You mentioned that this is likely to be a bug in Xlib, and not 
>emacs.  In any case, will this code change be adopted in your 
>emacs source pool, or will I need to pursue this with the Xlib 
>maintainers?
>
>TEST PROCEDURE
>--------------
>Using the original distribution, repeatedly (around 5 times) I issued:
>
>       # emacs&
>       [1] 482828
>
>Each time I observed the error:
>
>       emacs: Cannot connect to X server 16.176.233.71:0.0.
>       Check the DISPLAY environment variable or use `-d'.
>       Also use the `xhost' program to verify that it is set to permit
>       connections from your machine.
>
>After rebuilding emacs with your modifications, I issued:
>
>       # ./emacs-21.2/src/emacs &
>       [1] 482871
>
>It succeeded everytime.
>
>I repeated this sequence of tests several times with the same results.
>
>NOTE: the timing issue is exacerbated by starting emacs in the 
>background.  When starting in the foreground the timing 
>problem only occurs some of the time.
>
>Regards,
>Matt.
>
>
>>-----Original Message-----
>>From: Matt Muggeridge [mailto:Matt.Muggeridge@compaq.com]
>>Sent: Tuesday, 2 July 2002 7:25 AM
>>To: 'rms@gnu.org'; Matt.Muggeridge@hp.com
>>Cc: bug-gnu-emacs@gnu.org
>>Subject: RE: Emacs - cannot connect to X server
>>
>>
>>Richard,
>>
>>Sorry for the delay, I'm just back from vacation.
>>
>>Just to let you know where I am up to with this.
>>
>>I tested your suggested modifications and it worked as hoped.  
>>However, before I can claim conclusively that this solved the 
>>problem, I wanted to reproduce the problem I was having with 
>>the distribution emacs.  As of this morning, I have only been 
>>able to reproduce the original problem once.  Subsequent 
>>attempts did not show the problem.
>>
>>I'll continue testing this and keep you informed.
>>
>>Matt.
>>
>>>-----Original Message-----
>>>From: Richard Stallman [mailto:rms@gnu.org]
>>>Sent: Friday, 21 June 2002 7:42 PM
>>>To: Matt.Muggeridge@hp.com
>>>Cc: bug-gnu-emacs@gnu.org
>>>Subject: Re: Emacs - cannot connect to X server
>>>
>>>
>>>    I do not understand how emacs connects to the X server, 
>>>but I am suspicious
>>>    of timeouts.  Could it be that emacs does not wait long 
>>>enough to establish
>>>    an X-session over a slow link?
>>>
>>>It IS possible, because Emacs (on some systems) gets alarm signals
>>>regularly to "poll for input".  Perhaps the signal causes a problem
>>>of not "waiting" enough.  (I'd say that is a bug in Xlib if it 
>>>happens.)
>>>
>>>Could you see if this patch makes the problem go away?
>>>It may not be something we really want to install, though.
>>>
>>>*** xterm.c.~1.736.~ Thu Jun 13 18:28:04 2002
>>>--- xterm.c  Thu Jun 20 19:17:47 2002
>>>***************
>>>*** 14657,14666 ****
>>>--- 14657,14668 ----
>>>     argv[argc++] = "-xrm";
>>>     argv[argc++] = xrm_option;
>>>        }
>>>+     stop_polling ();
>>>      dpy = XtOpenDisplay (Xt_app_con, XSTRING (display_name)->data,
>>>                      resource_name, EMACS_CLASS,
>>>                      emacs_options, XtNumber (emacs_options),
>>>                      &argc, argv);
>>>+     start_polling ();
>>>  
>>>  #ifdef HAVE_X11XTR6
>>>      /* I think this is to compensate for XtSetLanguageProc.  */
>>>
>>
>