Re: xterm doesn't open on start (was: checkX problems)
Christopher Faylor wrote: On Thu, Dec 03, 2009 at 12:25:14AM +0100, Lothar Brendel wrote: More information as promised, after getting the new run and checkX (run2) packages announced this morning. $ checkX -v run2 0.3.2 0.3.2 announced? I didn't get any such message, and setup still only offers 0.3.1-1 to me. http://cygwin.com/ml/cygwin-announce/2009-12/msg2.html http://cygwin.com/ml/cygwin/2009-12/msg00079.html Thanx. I had just focused on cygwin-xfree, but indeed run2 is more general. Ciao Lothar -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: xterm doesn't open on start (was: checkX problems)
Hi! More information as promised, after getting the new run and checkX (run2) packages announced this morning. $ checkX -v run2 0.3.2 0.3.2 announced? I didn't get any such message, and setup still only offers 0.3.1-1 to me. vhaisbtim...@isb-timaresbrian-lt ~ $ XWin -multiwindow [1] 5004 vhaisbtim...@isb-timaresbrian-lt ~ $ Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.7.1.0 (10701000) Build Date: 2009-11-11 - UNQUOTE - Yes, the log didn't show anything unusual. (BTW: You got it from /var/log/XWin.log.0, not from stdout, right?) After quitting and destroying any processes from a DOS window, trying startxwin.bat with echo on First off all, nothing appeared (no X icon, no window). [...] At this point I run Cygwin Bash Shell and from that window I run startxwin.bat and it works fine, even after closing the Cygwin Bash Shell. Brief, running ``startxwin.bat'' from the Cygwin Bash Shell works while running it from a Windows Prompt (DOS window) does not. Right? Ok, same check over there. In the Windows Prompt: C:\cygwin\bin\run XWin What does happen? Nothing? Asks Lothar -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: xterm doesn't open on start (was: checkX problems)
Timares, Brian (Patriot) wrote: Lothar Brendel wrote: [...] Thus, once more: What does md5sum /usr/bin/checkX yield? a827086e9cbb331ef49d416b3cb1b135 or a36409714f5ce9d01e8dfb4cb38b7216? The 2nd: vhaisbtim...@isb-timaresbrian-lt ~ $ md5sum /usr/bin/checkX a36409714f5ce9d01e8dfb4cb38b7216 */usr/bin/checkX ... and that's the checksum for the version 0.3.0 of checkX! $ checkX -v run2 0.3.0 Ok, yes, that's an easier version check :-) So, you've got the situation I surmised in http://cygwin.com/ml/cygwin-xfree/2009-11/msg00200.html I.e. you *don't* have the new version (0.3.1) of the run2-package installed. Install that and retry, please. Ciao Lothar -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: xterm doesn't open on start (was: checkX problems)
Timares, Brian (Patriot) wrote: Lothar Brendel wrote: Timares, Brian (Patriot) wrote: Lothar Brendel wrote: $ checkX -v run2 0.3.0 So, you've got the situation I surmised in http://cygwin.com/ml/cygwin-xfree/2009-11/msg00200.html Grr, I saw that, went and _thought_ I got the right version but it seems the right version wasn't avaiable at the time and I got fooled by the 0.3.0-1 to think 0.3.1. I have carefully upgraded, and when running Setup17.exe I saw it wanted to revert, but I didn't let it. Exactly, the evil setup tries to revert it to 0.3.0-1 every time. Quite easy to forget keeping an eye on that when tinkering with other packages. The X window showed up, but it blew up real good (the windows disappeared, then the X icon. After a rebootit didn't launch at all. I ran startxwin.sh from the Cygwin Bash Shell, and it started. At least we're getting *somewhere* :-) Ok, what happens when entering the two vital commands by hand in the the Cygwin Bash Shell (waiting with the second until the X-icon has appeared)? XWin -multiwin xterm -display :0 Reproducible success? Asks Lothar -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: xterm doesn't open on start (was: checkX problems)
Timares, Brian (Patriot) wrote: Just to be clear from the start, Cygwin 1.7 not 1.5. ACK. [...] i) ```time checkX -t 12'' How long does it take? vhaisbtim...@isb-timaresbrian-lt ~ $ time checkX -t 12 real0m0.098s user0m0.046s sys 0m0.031s And *that* shouldn't happen! I don't quite get your VPN setup, but it being active *may* cause a delay in getting up the X server, and that *may* cause xterm to loose its patience. ii) ``startxwin.sh'' Any messages? Yes, see below, but after reviewing it all I tried it with various items on and off and having the One-VA VPN client (Cisco VPN Client 5) off makes the difference. It is odd, though, that if I run startxwin.sh again, it works the second time, even though the VPN is on. Not really, I think. The message xterm Xt error: Can't open display: 127.0.0.1:0.0 indicates that xterm didn't find the X server being up. And the reason is ``checkX'' not doing its job, namely waiting until it is really up. If you then start ``startxwin.sh'' again, it complains about an X server already being up, but at least xterm can finally connect. Thus, once more: What does md5sum /usr/bin/checkX yield? a827086e9cbb331ef49d416b3cb1b135 or a36409714f5ce9d01e8dfb4cb38b7216? Asks Lothar -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: xterm doesn't open on start (was: checkX problems)
Timares, Brian (Patriot) wrote: Lothar Brendel wrote: Timares, Brian (Patriot) wrote: Lothar Brendel wrote: My guess: It's the old checkX-problem again because you're using version 0.3.0-1 of the run2-package. Do to some reason unknown to me, that's the default version. But we need 0.3.1-1, which you only get when Tried it, including changing XWin Server to C:\cygwin\bin\run2.exe /usr/bin/startxwin.bat That was a misunderstanding. I didn't mean to use ``run2'' instead of ``run'' but to verify that the version of the *package* 'run2' (containing ``checkX'') is the most recent one. Did you do that? You were clear. I did get the 0.3.1-1 and it showed up just as you said. IC, but could you please perform the following two tests nevertheless? First open Cygwin's standard bash console, then enter: i) ```time checkX -t 12'' How long does it take? ii) ``startxwin.sh'' Any messages? Ciao Lothar -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: xterm doesn't open on start (was: checkX problems)
Timares, Brian (Patriot) wrote: [...] Nothing works. 1.7 doesn't work for me out-of-the-box (yes, I ripped it all out and tried it fresh :-) I open a DOS box and check processes and see bash running with an l or a 1 in the left columnn, but nothing appears. If I launch an Xterm it opens up. It seems some of the login thing happen, but when I add in my ssh-agent starting script, since it requires input, it fails (http://mah.everybody.org/docs/ssh is the script I use). Any other ideas? Doen't look like the issue http://cygwin.com/ml/cygwin-xfree/2009-11/msg00174.html to me. My guess: It's the old checkX-problem again because you're using version 0.3.0-1 of the run2-package. Do to some reason unknown to me, that's the default version. But we need 0.3.1-1, which you only get when explicitely (triple-)clicking its circular double-arrow (how's that thingy called BTW?) in the Utils category. Maybe Chuck can tell why we don't get the new version as default. Ciao Lothar -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: checkX problems
Thomas Dickey wrote: On Thu, 26 Nov 2009, Lothar Brendel wrote: [...] Hence, to make Cygwin/X+xterm run out of the box (using the start menu shortcut), you have to install the CJK fonts. One more noob-question, otoh, (discarding run-out-of-the-box, since that doesn't give a good solution), What's wrong with it running out-of-the-box? For somebody new to Cygwin it's a positive experience when the XWin Server shortcut actually opens an xterm. Which font-package does provide the CJK fonts? I tried several ones but up to now in vain. BTW: Following Ken's info (There are three packages: font-isas-misc, font-jis-misc, and font-daewoo-misc.), I found out to need font-daewoo-misc *and* font-isas-misc to make xterm happy. Ciao Lothar -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: xterm doesn't open on start (was: checkX problems)
Timares, Brian (Patriot) wrote: Lothar Brendel wrote: [...] My guess: It's the old checkX-problem again because you're using version 0.3.0-1 of the run2-package. Do to some reason unknown to me, that's the default version. But we need 0.3.1-1, which you only get when explicitely (triple-)clicking its circular double-arrow (how's that thingy called BTW?) in the Utils category. Tried it, including changing XWin Server to C:\cygwin\bin\run2.exe /usr/bin/startxwin.bat That was a misunderstanding. I didn't mean to use ``run2'' instead of ``run'' but to verify that the version of the *package* 'run2' (containing ``checkX'') is the most recent one. Did you do that? Asks Lothar -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: checkX problems
Charles Wilson wrote: Lothar Brendel wrote: It should list, but it doesn't: $ grep -A9 '@ run2' setup-2.ini ^^^ This was the clue. As it happens, the union mount stuff had an override for setup.hint, but not the entire directory. So, the tarballs themselves magically showed up in the release-2 area when I installed them in the release/ area, but release-2 retained the old setup.hint. Fixed. ACK. libustr1 was pulled in now. Unfortunately the situatiuon with ``startxwin.bat'' is worse now: * ``checkX -t 12'' still doesn't wait (?!?) * After again inserting a sleep between checkXing and starting the xterm, the latter is marginally successful: The process is shown as running but no xterm is showing up :-( I really would investigate this further, but I only get diagnostic output from ``checkX'' (--verbose or --debug) when running it from within an xterm, and that's obviously pointless. Thus, how to obtain output from ``checkX`` in Windows' Command Prompt, how to get it in Cygwin's bash window? Asks Lothar -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: checkX problems
Charles Wilson wrote: Lothar Brendel wrote: Unfortunately the situatiuon with ``startxwin.bat'' is worse now: * ``checkX -t 12'' still doesn't wait (?!?) I can't reproduce this. Stupid me, sorry. When updating to pull in libustr1, run2 was accidently reverted to 0.3.0-1. * After again inserting a sleep between checkXing and starting the xterm, the latter is marginally successful: The process is shown as running but no xterm is showing up :-( That's an xterm/XWin issue. Errh, yes. Hence, to make Cygwin/X+xterm run out of the box (using the start menu shortcut), you have to install the CJK fonts. One more noob-question, sorry: Which font-package does provide the CJK fonts? I tried several ones but up to now in vain. Ciao Lothar -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: checkX problems
Charles Wilson wrote: I've integrated Lothar's patch into run2/checkX (along with some other internal changes), and published a test release. Please try run-0.3.1-1 and let me know if it fixes your problems with checkX. checkX fails due to a missing cygustr-1.dll. That's contained in which package? Asks Lothar -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: checkX problems
Charles Wilson wrote: Lothar Brendel wrote: checkX fails due to a missing cygustr-1.dll. That's contained in which package? From http://cygwin.com/packages/ and typing in 'cygustr-1.dll', I get: Great, thanx for that one. This *should* have been installed by setup automatically, as the run2 package now lists libustr1 as a dependency. It should list, but it doesn't: $ grep -A9 '@ run2' setup-2.ini @ run2 sdesc: An enhanced version of the 'run' application launcher ldesc: Launches console applications without an console. Uses an xml configuration file to control environment settings and target command line options. Optionally, checks for a running X server and launches one of two alternate targets based on X server status. Also provides the checkX utility. category: Utils requires: cygwin libxml2 libiconv2 zlib0 version: 0.3.1-1 Ciao Lothar -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Cygwin error
baseball07 wrote: Hi everyone I am getting this error when I try and locally access the Linux machines in my department and try and run a program called Cadence. Does anyone know what this means? Yes, the remote X server can't connect to your local machine, the path to which is contained in the variable DISPLAY. The latter is unset in your case, most probably because you need to login with ssh -X. Ciao Lothar -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: checkX problems
Charles Wilson wrote:
[...]
The call to XOpenDisplay can take up to 12 seconds. Suppose the main
thread times out after say 5 seconds, and then just after that we
have a *successful* return in the worker thread. The worker thread
tries to get the mutex:
+ (*(data-xclosedis))(dpy);
+ pthread_mutex_lock (mtx_xopenOK);
But the main thread, if you follow the timed-out codepath, never
releases the mutex.
Ok, this can be cured by
if (pthread_cond_timedwait (cv_xopenOK, mtx_xopenOK, then) ==
ETIMEDOUT) {
xopenOK = XSERV_TIMEDOUT; /* it's okay, we have the mutex */
xopenTrying = 0; /* allow open_display() to give up */
+ pthread_mutex_unlock(mtx_xopenOK); /* allow for a last minute change
*/
}/* else open_display() was successful */
pthread_detach(id); /* leave open_display() on its own */
But the problem is not so much destroying a locked mutex, but rather locking
a destroyed mutex, right?
This happens in your race condition but also whenever ``delay'' is shorter
than the time spent in a successful XOpenDisplay(). The failure doesn't
really harm, but we can be less dirty by checking the result of
pthread_mutex_unlock(), cf. the new patch.
[...]
So, I'm just going to leave it, and take your patch as-is.
Maybe you consider the new one instead.
Thanks!
My pleasure!
Ciao
Lothar
--- checkX.c-0.3.0 2009-06-15 02:29:07.0 +0200
+++ checkX.c 2009-11-15 12:32:24.0 +0100
@@ -32,6 +32,7 @@
#endif
#include stdio.h
+#include errno.h
#if HAVE_SYS_TYPES_H
# include sys/types.h
@@ -102,7 +103,8 @@
static pthread_mutex_t mtx_xopenOK;
static pthread_cond_t cv_xopenOK;
-static int xopenOK = XSERV_TIMEDOUT;
+static int xopenOK;
+static int xopenTrying;
static const char* XLIBfmt = cygX11-%d.dll;
static const char* DefaultAppendPath = /usr/X11R6/bin SEP_CHAR
/usr/bin;
@@ -314,6 +316,9 @@
timespec_t delta;
timespec_t then;
+ xopenTrying = delay!=0.0; /* false actually means: try once */
+ xopenOK = XSERV_NOTFOUND; /* a pessimistic start out */
+
computeTimespec(fabs(delay), delta);
debugMsg(1, (%s) Using delay of %d secs, %ld nanosecs (%5.2f),
__func__,
delta.tv_sec, delta.tv_nsec,
@@ -333,15 +338,15 @@
if (delay != 0.0) {
clock_gettime(CLOCK_REALTIME, now);
timerspec_add(now, delta, then);
-pthread_cond_timedwait (cv_xopenOK, mtx_xopenOK, then);
- }
-
- pthread_mutex_unlock(mtx_xopenOK);
-
- if (delay != 0.0) {
-pthread_detach(id);
+if (pthread_cond_timedwait (cv_xopenOK, mtx_xopenOK, then) ==
ETIMEDOUT) {
+ xopenOK = XSERV_TIMEDOUT; /* it's okay, we have the lock */
+ xopenTrying = 0; /* allow open_display() to give up */
+ pthread_mutex_unlock(mtx_xopenOK); /* but also allow for a last
minute change */
+}/* else open_display() was successful */
+pthread_detach(id); /* leave it on its own */
} else {
-pthread_join(id, (void*)status);
+pthread_mutex_unlock(mtx_xopenOK); /* allow open_display() to set
xopenOK */
+pthread_join(id, (void*)status); /* and wait for it */
}
pthread_mutex_destroy(mtx_xopenOK);
@@ -357,19 +362,20 @@
open_display(void* /* WorkerThreadData* */ v)
{
Display* dpy;
- int rc = 0;
WorkerThreadData* data = (WorkerThreadData*)v;
- if( (dpy = (*(data-xopendis))(data-displayname)) == NULL ) {
-rc = 1;
- } else {
-(*(data-xclosedis))(dpy);
-rc = 0;
- }
- pthread_mutex_lock (mtx_xopenOK);
- xopenOK = rc;
- pthread_cond_signal(cv_xopenOK);
- pthread_mutex_unlock (mtx_xopenOK);
+ do
+if((dpy = (*(data-xopendis))(data-displayname))) {
+ (*(data-xclosedis))(dpy);
+ if (pthread_mutex_lock (mtx_xopenOK)) /* the mutex may already be
destroyed */
+ break;
+ else {
+ xopenOK = XSERV_FOUND;
+ pthread_cond_signal(cv_xopenOK);
+ pthread_mutex_unlock (mtx_xopenOK);
+ }
+}
+ while (xopenTrying xopenOK == XSERV_NOTFOUND);
pthread_exit((void*)0);
}
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: checkX problems
Lothar Brendel wrote: [...] The failure doesn't really harm, but we can be less dirty by checking the result of pthread_mutex_unlock(), cf. the new patch. Correction: I meant the result of pthread_mutex_lock() (in open_display()). Ciao Lothar -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: checkX problems
Charles Wilson wrote: [...] AFAICT, the cure for all of these problems is worse than the disease -- and the only *total* fix is for the main thread to always join() the worker. Which is precisely what we want to avoid. ACK and thanx for the explanations. Ciao Lothar -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: checkX problems
Charles Wilson wrote: [...] run.exe is peculiar. The first argument is the target, and IF the VERY NEXT argument is -wait, run usurps that argument. That is, run will invoke: checkX other args and checkX will never see -wait. So, what does run.exe do with -wait? It...waits. run.exe won't exit, until after the inferior does. Could you please clarify an issue here? (Sorry, it seems, I wronged to ``run'' in the previous posts.) In a Windows command prompt (being somewhere on C:) I put the line \cygwin\bin\run -p /usr/bin sleep -wait 5 into a file ``dosleep.bat''. Executing that BAT-script (w/o any wrapper), it *does* sleep. Typing that very line directly at the prompt lets ``run'' return immediately, though. Can you confirm this behaviour? Looking forward to reading your patches to address any of these problems. It shouldn't be too hard to add an option to checkX to make it retry if ECONNREFUSED. This would have to manually track the elapsed time for each attempt, charging against the specified -t waittime. Another possibility would be an option ``-n'' to specify the number of retries. Just look at run2-0.3.0/lib/checkX.c::try_with_timeout(). Some function signatures might need to be changed in order to pass opt.retry down to that level, but it'd be a nice short project for someone. I'll try to get to this but it'll be a few weeks, unless somebody sends me a patch sooner. I'd volunteer for that. How/where do I upload? Asks Lothar -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: 'run xterm' fails to open a window
Mike Ayers wrote: [...] Apparently, run.exe is not providing stdout/stderr to dump to. Is that by chance due to the fact that run.exe is compiled with -mwindows, i.e. as GUI? And am I the only one for whom this has further consequences? E.g. in a Windows command prompt or a non-X11 cygwin-console, the command run sleep -wait 5 does *not* wait for the sleep to terminate. Moreover run false -wait does *not* set %errorlevel% to 1. Ciao Lothar -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
run.exe and startxwin.bat [was: 'run xterm' fails to open a window]
Mike Ayers wrote: From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree- ow...@cygwin.com] On Behalf Of Lothar Brendel Sent: Tuesday, November 10, 2009 4:52 PM E.g. in a Windows command prompt or a non-X11 cygwin-console, the command run sleep -wait 5 does *not* wait for the sleep to terminate. Moreover run false -wait does *not* set %errorlevel% to 1. Why are you using run for these? I normally don't. It was what I boiled down the non-functioning line %RUN% checkX -wait -d %DISPLAY% -t 12 in startxwin.bat (from xinit-1.1.1-6.tar.bz2) to. Like that, the -wait has no effect and a non-running X-server isn't reflected in %errorlevel%, either. And (of course) I can confirm the correct behaviour when using sh.exe instead of run.exe. Which brings us to the question of using run.exe in startxwin.bat. I don't see the point of hoping for a windowless console there, since a BAT-script always opens a window anyway (even when starting with @echo off and outputting nothing). Hence, wouldn't be sh.exe instead of run.exe the right thing for startxwin.bat? Asks Lothar -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
