Re: emacs-x11 takes 30-40 sec to open after upgrading to cygwin-1.7
On 29/03/2010 11:33, Dan Tsafrir wrote: After I've upgraded to cygwin-1.7 my emacs takes 30-40 seconds to open. Following http://x.cygwin.com/docs/faq/cygwin-x-faq.html#poor-performance, disabling my antivirus has no affect on emacs's opening time. As far as I can tell other X programs behave similarly to the way they did before the upgrade. Any help would be appreciated. The output of 'cygcheck -s -v -r' is attached. LANG = 'C.UTF-8' You are probably being bitten by [1] As far as I can tell, this is a general problem with X, but cygwin unfortunately encounters it in a default install because (a) the default locale is a UTF-8 locale, and (b) we don't install the CJK fonts by default. Workarounds you might try are (a) install the font packages font-isas-misc, font-jis-misc and font-daewoo-misc (and restart your server), or (b) set your locale to a non-UTF-8 one. We need to do something about this, but as the discussion in the bug should make clear, we're not sure what :-) [1] http://sourceware.org/bugzilla/show_bug.cgi?id=10948 -- 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: Xwin crashes in multiwindow
On 29/03/2010 06:46, Rodrigo Medina wrote: I have found that with some programs XWin crashes giving segmentation Fault. The problem arises when the client program is stopped using the X button of the Windows window. The cygcheck output and the XWin log file are attached. 2010-03-29 00:06:53 winInitMultiWindowWM - Warning: Locale not supported by X. I'm kind of puzzled to see this, and I'm wondering what locale you have set, but your cygcheck output seems to have been generated using cygcheck -s rather than cygcheck -svr, as recommended by the problem reporting page linked at the bottom of this email, so it doesn't record your environment. In case you need it, I can also attach the source of of some of the programs that fail. Unfortunately the problem does not always appear, particulary for very simple programs it does not arise. What would be most useful would be using gdb to get a backtrace for the X server when it crashes. Apart from the XWin.0.log the following messages appear in the terminal window used for starting the server Segmentation fault at address 0x1c Fatal server error: Caught signal 11 (Segmentation fault). Server aborting $ [mi] EQ overflowing. The server is probably stuck in an infinite loop. The message says that the server is aborting, but actually it does not disappear. It cannot be stopped with the exit button in the servers menu. After trying that the following message appears $ winDeinitMultiWindowWM - Noting shutdown in progress [mi] EQ overflowing. The server is probably stuck in an infinite loop. [mi] EQ overflowing. The server is probably stuck in an infinite loop. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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: Problems getting started in Cgywin/X
On 28/03/2010 20:40, David Sicks wrote: I want to run DDLab and I have Windows XP. DDLab can be run using Cygwin/X among other things, and I decided to use it. Coming out of the Cygwin/X setup, I got the following error messages: warning: locale is not supported by c library, locale unchanged Also, I tried s.t.a.r.t.x.d.m.c.p..b.a.t. in bash 3.2 and got the following fatal error message: /usc/bin/xwin -query 10.0.0.1 -nodirection -lesspointer I've not used Linux before. When I googled the locale is not supported by c library message, I found a bewildering array of prior similar problems, numerous futile requests for help, and (I think) some fixes that may have worked that I didn't understand. Can you tell me how to get on track? Chapter 4 of the Cygwin/X user's guide [1] should tell you how to do whatever it is you want to do. If you still have problems, please read [2] [1] http://x.cygwin.com/docs/ug/using.html [2] http://cygwin.com/problems.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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: 1.7.2: ssh -X unresponsive until xauth PPID killed
On 27/03/2010 21:53, Mark McConnell wrote: (Please forgive the repost - this version has the attachments mentioned) After installing Cygwin 1.7.2 for the first time on Windows Server 2008 SP2, I discovered that I could not connect to a remote host using Cygwin's ssh, if X is forwarded. ssh -X host or ssh -Y host : program becomes unresponsive. I've attached the output of cygcheck -s -v -r to this message, and /var/log/XWin.0.log. I should mention as an aside that there are other clues that my Cygwin installation is flawed (a local gvim gui will not display, man dumps core). Given that, I'm thinking that the problem you describe with the xauth subprocess is probably symptomatic of some deeper problem with you installation or environment. You should probably ask for help on the main cygwin list. Below, I describe two experiments that indicate that my X forwarding problem is somehow related to xauth* and its PPID: ### 'ssh -X host gui' displays if the PPID of xauth* is killed ### First, I open a new mintty window within the Cygwin environment and issue the command to start gvim on the remote server, using the forwarded X display. No gui is displayed. The cursor returns below the prompt. ^d or ^c do not terminate the process ( however, I can suspend it from that window by typing ^z, and I can return it to the foreground with fgjob ). -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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: USER/GDI Objects leak with (XWin.exe) Cygwin/X X Server Verion 1.7.6, Build Date 2010-03-18
On 22/03/2010 18:38, Amal Khailtash wrote: My Windows XP USER and GDI object counts, for process XWin.exe, keep going up even if I leave my PC running and doing nothing. The increase eventually makes my windows title-bars and and menu bars disappear and I need to reboot to be able to work again. How are you measuring these object counts? It's unclear from what you write if you have any X clients connected to your X server while the leak is occurring. It's interesting that, from your cygcheck output, you seem to have a native TCL installed, as that has been mentioned previously associated with some source of resource leak problem (see [1]), although I've never been able to reproduce it. [1] http://sourceware.org/ml/cygwin-xfree/2009-02/msg00184.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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: USER/GDI Objects leak with (XWin.exe) Cygwin/X X Server Verion 1.7.6, Build Date 2010-03-18
Hello Jon, Thanks for looking into this. I do have native TCL installed as well, but I am not really running anything locally. The only client I run is a Linux Konsole window launched by an SSH command. Once I have a remote terminal, I launch my simulation tool (ModelSim). I watch the resources using windows Task Manager. Do you think that ModelSim or Konsole are eating up resources? Although, even when I quit those programs, until I close XWin.exe, the resources are not freed! Cheers,-- Amal - Original Message From: Jon TURNEY jon.tur...@dronecode.org.uk To: cygwin-xfree@cygwin.com Cc: akhailt...@yahoo.com Sent: Mon, March 29, 2010 12:55:18 PM Subject: Re: USER/GDI Objects leak with (XWin.exe) Cygwin/X X Server Verion 1.7.6, Build Date 2010-03-18 On 22/03/2010 18:38, Amal Khailtash wrote: My Windows XP USER and GDI object counts, for process XWin.exe, keep going up even if I leave my PC running and doing nothing. The increase eventually makes my windows title-bars and and menu bars disappear and I need to reboot to be able to work again. How are you measuring these object counts? It's unclear from what you write if you have any X clients connected to your X server while the leak is occurring. It's interesting that, from your cygcheck output, you seem to have a native TCL installed, as that has been mentioned previously associated with some source of resource leak problem (see [1]), although I've never been able to reproduce it. [1] http://sourceware.org/ml/cygwin-xfree/2009-02/msg00184.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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: bug report/suggested temp. patch: handling bursts of sent keys
On 20/03/2010 16:32, Mark Lillibridge wrote: On February 23, 2010, Jon Turney wrote: On 13/02/2010 20:24, Mark Lillibridge wrote: Jon wrote: Thanks for the patch. Have you actually tested that this resolves your problem? Yes. Of course, really, really large bursts will still fail, but they should be very rare. Perhaps you might try the attached patch, instead, and see if that helps. Yes, your (previously) attached patch seems to solve the problem without wasting memory or only working for a finite number of keys. Nice job. What's the next step towards getting this patch added to the source/sent upstream/to Xming? Yaakov, Can you pull this patch and include it in the next X server release, please. Sadly this isn't quite a complete solution: there's still the problem in multiwindow mode that Windows uses a modal loop when resizing/moving a window, so the X server code gets no chance to do anything then. You can easily demonstrate this by resizing the frame of an X window, moving the mouse continuously for a number of seconds, and then notice that X window doesn't react to the queued size changes until the mouse button is released. The following changes since commit 579715f830fbbca9e1ecb17dc18176132f5969e7: Rami Ylimaki (1): os: Prevent backtrace from being stopped in noreturn functions. are available in the git repository at: git://anongit.freedesktop.org/~jturney/xserver for-yaakov Jon TURNEY (1): Cygwin/X: Process one Windows message per wakeup, rather than all of them. hw/xwin/winblock.c | 23 --- hw/xwin/winwakeup.c |4 ++-- 2 files changed, 6 insertions(+), 21 deletions(-) -- 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: 1.7.2: ssh -X unresponsive until xauth PPID killed
2010/3/29 Jon TURNEY jon.tur...@dronecode.org.uk: On 27/03/2010 21:53, Mark McConnell wrote: (Please forgive the repost - this version has the attachments mentioned) After installing Cygwin 1.7.2 for the first time on Windows Server 2008 SP2, I discovered that I could not connect to a remote host using Cygwin's ssh, if X is forwarded. ssh -X host or ssh -Y host : program becomes unresponsive. I've attached the output of cygcheck -s -v -r to this message, and /var/log/XWin.0.log. I should mention as an aside that there are other clues that my Cygwin installation is flawed (a local gvim gui will not display, man dumps core). Given that, I'm thinking that the problem you describe with the xauth subprocess is probably symptomatic of some deeper problem with you installation or environment. You should probably ask for help on the main cygwin list. Below, I describe two experiments that indicate that my X forwarding problem is somehow related to xauth* and its PPID: ### 'ssh -X host gui' displays if the PPID of xauth* is killed ### First, I open a new mintty window within the Cygwin environment and issue the command to start gvim on the remote server, using the forwarded X display. No gui is displayed. The cursor returns below the prompt. ^d or ^c do not terminate the process ( however, I can suspend it from that window by typing ^z, and I can return it to the foreground with fgjob ). -- Jon TURNEY Volunteer Cygwin/X X Server maintainer Thank you, Jon. I'll give some thought to how to summarize the various problems I'm experiencing and send that to the main list. Mark -- -- 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: emacs-x11 takes 30-40 sec to open after upgrading to cygwin-1.7
On Mon, Mar 29, 2010 at 19:14, Jon TURNEY jon.tur...@dronecode.org.uk wrote: On 29/03/2010 11:33, Dan Tsafrir wrote: After I've upgraded to cygwin-1.7 my emacs takes 30-40 seconds to open. Following http://x.cygwin.com/docs/faq/cygwin-x-faq.html#poor-performance, disabling my antivirus has no affect on emacs's opening time. As far as I can tell other X programs behave similarly to the way they did before the upgrade. Any help would be appreciated. The output of 'cygcheck -s -v -r' is attached. LANG = 'C.UTF-8' You are probably being bitten by [1] [1] http://sourceware.org/bugzilla/show_bug.cgi?id=10948 I confirm the symptom described in [1] happening when I invoke emacs-x11; namely, emacs-x11 indeed consumes a lot of CPU upon startup. But, alas, the workarounds you suggest don't solve the problem. Specifically: As far as I can tell, this is a general problem with X, but cygwin unfortunately encounters it in a default install because (a) the default locale is a UTF-8 locale, and (b) we don't install the CJK fonts by default. Workarounds you might try are (a) install the font packages font-isas-misc, font-jis-misc and font-daewoo-misc (and restart your server), As can be seen in the cygcheck.out I've attached to my initial email, these fonts were/are already installed in my system: font-isas-misc 1.0.1-1 font-jis-misc 1.0.1-1 font-daewoo-misc1.0.1-1 (In fact, I've installed all the available fonts in cygwin setup.) or (b) set your locale to a non-UTF-8 one. I've conducted a few repeated measurements and it looks as though setting LANG to be en_US somewhat reduces the start time of emacs-x11: instead of ~30 seconds with LANG=C.UTF-8, it take ~27 seconds LANG=en_US. While this is ~10% less, waiting 27 seconds for emacs to open still seems unreasonable. Any other ideas? Thanks, --Dan -- 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: 1.7.2: ssh -X unresponsive until xauth PPID killed
I turned off Data Execution Protection for all except crucial Windows programs, and the XWin problems I described were resolved. Thanks for your patience, Mark -- -- 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: 1.7.2: ssh -X unresponsive until xauth PPID killed
2010/3/29 Mark McConnell markd.mcconn...@gmail.com: I turned off Data Execution Protection for all except crucial Windows programs, and the XWin problems I described were resolved. Thanks for your patience, Mark -- I discovered afterward that this is related to FAQ #14. This Server 2008 is running Terminal Services, and that is the key fact. http://www.cygwin.com/faq/faq.setup.html#faq.setup.setup-fails-on-ts I'm sorry that faq escaped my attention. I didn't recognize the connection, since I set up Cygwin on a local console, not through Terminal Services; but now the relationship is obvious to me. Mark -- -- 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/
