Re: Cygwin slow on x64 systems
Hi Sagi and all others, Thanks Sagi for your investigation! This is great news that it could finally be tracked down. I am also suffering badly here from this speed drop. I haven't yet tried myself to revert this change to see whether it brings back speed but will certainly try to do so soon. What are our cygwin gurus (CGF,Corinna,?) saying about this? Can the results of these investigations be incorporated in a change in an upcoming version to get a more performant cygwin version? I know that in 1.7 codebase a lot has changed so it might not be that easy to transport these results to the current version. Beside of the fork problems the speed drop is (in my eyes) the other big problem of cygwin on x64. Thanks in advance, Roland, hoping that this problem gets cured soon -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: setup.exe crashes when downgrading gcc4
On 30 August 2010 13:43, Peter Münster wrote: >> - it seems, that it crashes now, whatever I do... > > Hello, > > I've found "the solution": instead of using mirror rz.ruhr-uni-bochum.de I > switched to mirror tu-dresden.de. Now there is no more crash! Good. The Bochum http mirror works fine for me, but the ftp one just stops during the download of setup.bz2, so it seems something's not right with that server. Which one were you using? Regarding the crash, I can only guess that the Bochum mirror's subdirectory in your Cygwin download directory had somehow got into an inconsistent state. Of course that shouldn't cause a crash, but if you do want to use that mirror again you could try deleting its subdirectory. If you do see the crash again, sending /var/log/setup.log.full may be helpful too. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: setup.exe crashes when downgrading gcc4
On Mon, Aug 30 2010, Peter Münster wrote: > - it seems, that it crashes now, whatever I do... Hello, I've found "the solution": instead of using mirror rz.ruhr-uni-bochum.de I switched to mirror tu-dresden.de. Now there is no more crash! Cheers, Peter -- Contact information: http://pmrb.free.fr/contact/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
xfig startup with latest user versions of xfig
Hi-- After updating to the latest version of xfig, I got the following error message from xfig when I ran (countr.fig is a new figure I am building): xfig countr.fig & -error message The app-defaults file (version: 3.2.4) is older than this version of xfig (3.2.5b). You should install the correct version or you may lose some features. This may be done with "make install" in the xfig source directory. --- I don't build cygwin routines myself. I assume that the setup routines take care of consistency requirements such as this, so I thought I should send you this note. Thanks! Carl Lund -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Unexpected results from grep 2.6.3-1
On 08/30/2010 05:08 PM, Christopher Faylor wrote: On Mon, Aug 30, 2010 at 01:22:48PM -0700, Robert Ross wrote: With grep 2.6.3-1, the following produces no output: echo "Hello world"> hi /bin/grep --include='*' 'world' * With grep 2.5.4-2, the output is "Hello world". It does seem strange but, if it's a bug, it's also evident on linux. It's already been reported and fixed upstream: http://lists.gnu.org/archive/html/bug-grep/2010-08/msg3.html -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Unexpected results from grep 2.6.3-1
On Mon, Aug 30, 2010 at 01:22:48PM -0700, Robert Ross wrote: >With grep 2.6.3-1, the following produces no output: > >echo "Hello world" > hi >/bin/grep --include='*' 'world' * > >With grep 2.5.4-2, the output is "Hello world". It does seem strange but, if it's a bug, it's also evident on linux. FWIW, grep --include='./*' world * works. The grep bug reporting page is here: http://savannah.gnu.org/bugs/?group=grep if you want to report it. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Building Mutt: configure: invalid value of canonical build
On 30.08.2010 23:52, Michael Ludwig wrote: The mutt mail reader shipping with Cygwin does not have SMTP enabled, which I'd like to give a try. So I tried to build mutt, but encountered problems. [... long whine about non-working build snipped ...] Did you use the ./prepare script first if building from Hg (Mercurial) rather than a tarball? If so, did you use setup.exe since to remove/upgrade autoconf, automake, or related packages? That might have invalidated symlinks. Also be sure not to mix MinGW and Cygwin utilities - this is a constant source of confusion. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Building Mutt: configure: invalid value of canonical build
The mutt mail reader shipping with Cygwin does not have SMTP enabled, which I'd like to give a try. So I tried to build mutt, but encountered problems. The machine is 64-Bit PC running Win7/64/Pro, and Cygwin, of course. I have both gcc 3 and 4 installed. ./configure --prefix=/usr/local/mutt --build=i686-pc \ --enable-imap --enable-smtp --enable-hcache --with-regex --with-ssl Note that I specified a (wrong) --build option, but read on and see below. Independently of that --build option, I got the following error: configure: error: cannot run /bin/sh ./config.sub The solution is easy: touch config.sub Got the same for install-sh, by the way. Now on to the main error. Trying again the same configure line. \,,,/ (o o) --oOOo-(_)-oOOo-- checking whether build environment is sane... yes /bin/sh: /usr/src/mutt-1.5.20-1.milu/orig/missing: No such file or directory configure: WARNING: `missing' script is too old or missing ... [don't know if the above is a problem] ... checking build system type... configure: error: invalid value of canonical build - It is only after receiving an error because of the script's failure to guess the build system that I added the --build option to configure. But obviously I didn't fill in a correct value. What should I try? -- Michael Ludwig -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Unexpected results from grep 2.6.3-1
With grep 2.6.3-1, the following produces no output: echo "Hello world" > hi /bin/grep --include='*' 'world' * With grep 2.5.4-2, the output is "Hello world". Rob -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: /dev/windows and select() [was Re: Slow response to keypresses in xorg-server-1.8.0-1]
On Aug 30 12:49, Brian Ford wrote: > On Mon, 30 Aug 2010, Corinna Vinschen wrote: > > > I applied a patch to Cygwin which should make select on /dev/windows > > fully functional. > > > > The blessed solution is to replace the call to MsgWaitForMultipleObjects > > with a call to MsgWaitForMultipleObjectsEx with the MWMO_INPUTAVAILABLE > > flag set. This flag is defined to do exactly what we need. > > Just wondering, does this also effect select/poll on sockets in either 1.7 > or 1.5? Not at all. It only affects select on /dev/windows. > A long time ago (1.5.18) I discovered a delay in select on sockets > wondered if this might have been related. The implementation of the socket-specific code in the select function has been rewritten from sratch for 1.7. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: /dev/windows and select() [was Re: Slow response to keypresses in xorg-server-1.8.0-1]
On Mon, 30 Aug 2010, Corinna Vinschen wrote: > I applied a patch to Cygwin which should make select on /dev/windows > fully functional. > > The blessed solution is to replace the call to MsgWaitForMultipleObjects > with a call to MsgWaitForMultipleObjectsEx with the MWMO_INPUTAVAILABLE > flag set. This flag is defined to do exactly what we need. Just wondering, does this also effect select/poll on sockets in either 1.7 or 1.5? I seem to remember a Windows event loop required for select on sockets and wasn't sure if this change would be related. A long time ago (1.5.18) I discovered a delay in select on sockets and wondered if this might have been related. I haven't retested in that long since I found a work-around ;-). -- Brian Ford Staff Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained crew... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 'test' utility behavior question.
On 2010-08-30 20:31, Eric Blake wrote: On 08/30/2010 11:27 AM, Oleksandr Gavenko wrote: $ /bin/test -d && echo ok ok $ /bin/test -d '' && echo ok || echo must_be_error must_be_error Both of these results match POSIX. Remember, POSIX describes different behaviors for one argument than for two arguments (for the one-argument case, the string "-d" is non-empty, so the result must be 0; for the two-argument case, the string "-d" is a unary operator, and there is no directory named ''). if [ -d $dir ]; then The bug is in your script. You forgot to use quoting or a bashism. Either of these fixes will correct your script (although the latter requires bash): if [ -d "$dir" ]; then if [[ -d $dir ]]; then This is not cygwin-specific. You right! Sorry, I miss this when read POSIX: 1 argument: Exit true (0) if $1 is not null; otherwise, exit false. -- Best regards! -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 'test' utility behavior question.
On 08/30/2010 11:27 AM, Oleksandr Gavenko wrote: $ /bin/test -d && echo ok ok $ /bin/test -d '' && echo ok || echo must_be_error must_be_error Both of these results match POSIX. Remember, POSIX describes different behaviors for one argument than for two arguments (for the one-argument case, the string "-d" is non-empty, so the result must be 0; for the two-argument case, the string "-d" is a unary operator, and there is no directory named ''). if [ -d $dir ]; then The bug is in your script. You forgot to use quoting or a bashism. Either of these fixes will correct your script (although the latter requires bash): if [ -d "$dir" ]; then if [[ -d $dir ]]; then This is not cygwin-specific. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
'test' utility behavior question.
$ /bin/test -d && echo ok ok $ /bin/test -d '' && echo ok || echo must_be_error must_be_error POSIX require argument for -d, so behavior implementation depend. I can not check another 'test' implementation now. For me get error is more convenient, because this not break this code if $dir not defined: if [ -d $dir ]; then do-good-job; else info-user-about-missing-dir; fi To resolve upper code I rewrite condition in POSIX compatible form: [ -d "$dir" ] -- Best regards! -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: SSH - Can't Login (3rd Post)
On Mon, Aug 30, 2010 at 18:03, Auteria W. Winzer Jr. wrote: > I checked the following below. The user's home directory has the proper > permissions (755), the .ssh directory is 700, and the files underneath the > .ssh > directory is 600. By default StrictModes is set to no. > > I still can't log in. > > Any help will be greatly appreciated. > Help us helping you. Begin by posting a relevant part of the SERVER side log, with at least a DEBUG1 level. Also the requested information as stated in http://cygwin.com/problems.html might be useful... > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Regards, ___ Julio Costa -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: SSH - Can't Login (3rd Post)
I checked the following below. The user's home directory has the proper permissions (755), the .ssh directory is 700, and the files underneath the .ssh directory is 600. By default StrictModes is set to no. I still can't log in. Any help will be greatly appreciated. Thanks, and regards, Mr. Auteria W. Winzer Jr. - Original Message From: Slide To: cygwin@cygwin.com Sent: Sat, August 28, 2010 4:56:30 PM Subject: Re: SSH - Can't Login (3rd Post) On Sat, Aug 28, 2010 at 4:34 PM, Auteria W. Winzer Jr. wrote: > I've posted this 3 times now. I'm wondering if anyone from the Cygwin staff is > receiving it. I've been an outstanding member of the mailing list for a very > long time. Anyway, here's my issue: > > I've set up SSH with no problems in the past, yet when I try to log into itself > I get the following: > Check the following: ls -la /home//.ssh ls -la /home Does the .ssh folder have permissions 700 and files within 600? Do you have "StrictModes yes" in your sshd_conf file? If so, then the server will ignore the keys in the .ssh sub-directory if the home directory is writeable by anyone other than the Owner. slide -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Keyboard issue: unresponsive keystroke
On 08/30/2010 10:52 AM, Eric Vautier wrote: Hello all, I've used the US-International keyboard layout for ages without issues. Recently, I fired cygwin and noticed the "s" key was unresponsive. Did you check whether ~/.inputrc has DOS line endings? If so, run d2u on it, and see if that fixes things. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Keyboard issue: unresponsive keystroke
Hello all, I've used the US-International keyboard layout for ages without issues. Recently, I fired cygwin and noticed the "s" key was unresponsive. Restarting Vista didn't help. Changing to standard US layout before starting Cygwin didn't help. Restarting Cygwin didn't help. Scrapping the Cygwin directory (admittedly not the preferred uninstalling procedure) and re-doing the setup with a fresh setup.exe didn't help. Any pointers would be appreciated. Thanks, Eric -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin slow on x64 systems
On 8/30/2010 7:16 AM, Sagi Ben-Akiva wrote: 2. a. Moving the call to wait_for_sigthread from dll_crt0_1 to _dll_crt0 which calls dll_crt0_1. b. Deleting the call to WaitForSingleObject, i.e. : "Don't worry about sync_startup" I can confirm that the 2nd sub-change is the cause for the slowdown. Just curious, has the performance characteristics of your test changed with the lastest cygwin snapshot? The affected code has moved somewhat since revision 1.288. I wonder if we can move the call to wait_for_sigthread() further down in dll_crt0_0() to improve performance via concurrency. Perhaps as far down as right before we assign cygwin_finished_initializing to true? At first brush, it looks like the slowdown is caused by the slow thread startup. I wouldn't expect that Win64 thread start up to be any slower than Win32 but perhaps this is due to Wow64. MSDN [1] does document that there is some (small) extra thread allocation when on WOW64. Perhaps some independent testing in this regard might be helpful. Regards, -Edward 1. http://msdn.microsoft.com/en-us/library/aa384219%28VS.85%29.aspx -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Uninitialized variable usage in cygthread?
On 8/30/2010 10:45 AM, Corinna Vinschen wrote: What am I missing? cygthread::operator new(size_t) Thanks! -Edward -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: MANPATH not being cygpathed like PATH is?
On Fri, Aug 27, 2010 at 2:59 PM, Jeremy Bopp wrote: > On 8/27/2010 1:28 PM, Tim Visher wrote: >> Hello Everyone, >> >> I recently switched from setting up environment variables within my >> bash_profile/bashrc file and instead started setting them on the box >> I'm on. This works great for PATH. In Windows I set the values to >> c:/whateverwhatever and then when my terminal fires up they get >> cygpathed (I'm assuming) into the right /usr/etcetcetc. >> Unfortunately, I'm observing no such behavior with the MANPATH. I >> can't see any difference between it and the PATH value so I was >> wondering if this was something that cygwin does intentionally. > > Cygwin only processes a handful of environment variables automatically > in the way you expect. They include PATH, HOME, TMP, and TEMP if my > memory serves correctly. Anything else you need to do for yourself. > > The problem is that there is no general way to know what environment > variables should be processed, so an explicit list must be created and > maintained. Apparently, a minimal set was chosen which is usually > sufficient to get you into a Cygwin environment at which point you can > selectively handle further processing as necessary. > > For defining MANPATH within Windows, you could just specify it as Cygwin > wants it unless you have some non-Cygwin programs which also need to use > MANPATH. Thanks, Jeremy. That was basically the conclusion I'd come to before you mailed but it was good to have it confirmed. I've edited all the relevant PATHS and it all works now. -- In Christ, Timmy V. http://blog.twonegatives.com/ http://five.sentenc.es/ - Spend less time on e-mail -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Uninitialized variable usage in cygthread?
On Aug 30 10:26, Edward Lam wrote: > Hi, > > In looking at slowdown problem on x64 systems by Sagi Ben-Akiva, I > found some puzzling code that perhaps someone could enlighten me on. > I must be reading it wrong. > > Here's the code path that I'm tracing using cygwin-src-20100829.tar.bz2: > > - In dcrt0.cc, if dynamically_loaded is true, then we call sigproc_init(). > > - In sigproc.cc, sigproc_init() creates a new thread: > hwait_sig = new cygthread (wait_sig, 0, cygself, "sig"); > > - This calls the cygthread constructor for LPTHREAD_START_ROUTINE. > (Actually, this doesn't really matter because the constructor for > LPVOID_START_ROUTINE looks like it has the same problem.) > > - The cygthread constructor calls create(). But prior to this, the > following class members are initialized: > __name, func, arglen, arg, notify_detached > > - The following class members are NOT initialized (assuming that the > macro DEBUGGING is NOT set): > inuse, id, h, ev, thread_sync, stack_ptr, is_freerange > > - Ok, now the cygthread constructor calls cygthread::create() > > - In cygthread.cc, cygthread::create() immediately checks the value > of the variable "h". But as mentioned previously, this is a variable > that has not been initialized yet. > > > What am I missing? cygthread::operator new(size_t) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Uninitialized variable usage in cygthread?
Hi, In looking at slowdown problem on x64 systems by Sagi Ben-Akiva, I found some puzzling code that perhaps someone could enlighten me on. I must be reading it wrong. Here's the code path that I'm tracing using cygwin-src-20100829.tar.bz2: - In dcrt0.cc, if dynamically_loaded is true, then we call sigproc_init(). - In sigproc.cc, sigproc_init() creates a new thread: hwait_sig = new cygthread (wait_sig, 0, cygself, "sig"); - This calls the cygthread constructor for LPTHREAD_START_ROUTINE. (Actually, this doesn't really matter because the constructor for LPVOID_START_ROUTINE looks like it has the same problem.) - The cygthread constructor calls create(). But prior to this, the following class members are initialized: __name, func, arglen, arg, notify_detached - The following class members are NOT initialized (assuming that the macro DEBUGGING is NOT set): inuse, id, h, ev, thread_sync, stack_ptr, is_freerange - Ok, now the cygthread constructor calls cygthread::create() - In cygthread.cc, cygthread::create() immediately checks the value of the variable "h". But as mentioned previously, this is a variable that has not been initialized yet. What am I missing? Thanks, -Edward -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin slow on x64 systems
On 8/30/2010 7:16 AM, Sagi Ben-Akiva wrote: For the last couple of weeks I'm trying to identify the cause for cygwin slowdown on x64 machines which was reported by David Morgan about 6 months ago. You're my new hero. :) I then applied the changes one by one and built cygwin1.dll for each change, then I ran my test script again for each cygwin1.dll version and I found that the change to winsup/cygwin/dcrt0.cc from '2006/03/12 23:57:03' introduce this issue. For anyone interested in this, it's revision 1.288 of dcrt0.cc Web CVS link: http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/dcrt0.cc?cvsroot=src -Edward -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gitk unusable in cygwin-1.7.6-1 because tcltk-20080420-1 is native win32 app.
On 27 Aug 2010 19:33:36 +0100, Andy Koppe wrote: > It will be synced with the POSIX working directory again, except when > the path is too long or it's a "virtual" directory such as /proc. Thank you for summarizing the thread. I tried using the snapshot cygwin1-20100829.dll.bz2 and confirmed that gitk works okay again. One thing to note. I said in the previous mail that "gitk unusable in cygwin-1.7.6-1", but after more testing, I found I was wrong in saying that. The correct description of the problem in cygwin-1.7.6-1 was "gitk does work in a directory with only ascii characters in its path, but is unusable in a directory that contains a non-ascii character in its path." In the latter case, echo "puts [pwd]"|wish returned //?/PIPE . But I confirmed this was fixed and gitk works again in the snapshot cygwin1-20100829.dll.bz2 . I thank the developers for fixing this. -- neomjp -- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: /dev/windows and select() [was Re: Slow response to keypresses in xorg-server-1.8.0-1]
On 30/08/2010 12:23, Corinna Vinschen wrote: On Aug 29 14:39, Jon TURNEY wrote: On 08/08/2010 12:04, Andy Koppe wrote: On 7 August 2010 23:07, Jon TURNEY wrote: Hmmm, looking again at the implementation of select(), I don't immediately see that when waiting on /dev/windows, it checks that the message queue has old messages on it before waiting. The MSDN documentation for MsgWaitForMultipleObjects() seems to says that messages which had arrived before the last PeekMessage() etc. aren't considered new and so don't end the wait? I think you're right, a call to PeekMessage is needed for proper select() semantics: it shouldn't block if data is available for reading. Attached is a small test-case which seems to demonstrate this problem. Run ./dev-windows-select-test and observe select() blocks for the full timeout, despite the fact that the /dev/windows fd is ready for reading (and it reported as such as the end of the timeout) If you run './dev-windows-select-test -skip' to skip the PeekMessage(), select() returns immediately, indicating the /dev/windows fd is ready for reading. Again, thanks for the testcase. I applied a patch to Cygwin which should make select on /dev/windows fully functional. The blessed solution is to replace the call to MsgWaitForMultipleObjects with a call to MsgWaitForMultipleObjectsEx with the MWMO_INPUTAVAILABLE flag set. This flag is defined to do exactly what we need. The only downside is that this flag does not exist on NT4 and its usage results in an "invalid argument" error. So, for NT4, I added the workaround I described in my yesterday's soliloquy. I'm planning to release Cygwin 1.7.7 tomorrow at the latest, so please give it a test as soon as possible. Here's a binary DLL for testing (build w/o optimization, so it's probably a bit slow): http://cygwin.de/cygwin-177/new-cygwin1.dll.bz2 (md5sum: 7e07fd9eafd021697a0861c1ae4fa94e) Thanks Corinna :-) I tried that cygwin DLL with my test case, and with an X server with what I now realize is the workaround I'd applied reverted [1] and it seems to work fine. [1] http://cgit.freedesktop.org/~yselkowitz/xserver/commit/?h=cygwin-release-1.8&id=6da3190eacae2c2b021060f8fd9427816ac06f21 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: /dev/windows and select() [was Re: Slow response to keypresses in xorg-server-1.8.0-1]
On Aug 29 14:39, Jon TURNEY wrote: > On 08/08/2010 12:04, Andy Koppe wrote: > >On 7 August 2010 23:07, Jon TURNEY wrote: > >>Hmmm, looking again at the implementation of select(), I don't immediately > >>see that when waiting on /dev/windows, it checks that the message queue has > >>old messages on it before waiting. The MSDN documentation for > >>MsgWaitForMultipleObjects() seems to says that messages which had arrived > >>before the last PeekMessage() etc. aren't considered new and so don't end > >>the wait? > > > >I think you're right, a call to PeekMessage is needed for proper > >select() semantics: it shouldn't block if data is available for > >reading. > > Attached is a small test-case which seems to demonstrate this problem. > > Run ./dev-windows-select-test and observe select() blocks for the > full timeout, despite the fact that the /dev/windows fd is ready for > reading (and it reported as such as the end of the timeout) > > If you run './dev-windows-select-test -skip' to skip the > PeekMessage(), select() returns immediately, indicating the > /dev/windows fd is ready for reading. Again, thanks for the testcase. I applied a patch to Cygwin which should make select on /dev/windows fully functional. The blessed solution is to replace the call to MsgWaitForMultipleObjects with a call to MsgWaitForMultipleObjectsEx with the MWMO_INPUTAVAILABLE flag set. This flag is defined to do exactly what we need. The only downside is that this flag does not exist on NT4 and its usage results in an "invalid argument" error. So, for NT4, I added the workaround I described in my yesterday's soliloquy. I'm planning to release Cygwin 1.7.7 tomorrow at the latest, so please give it a test as soon as possible. Here's a binary DLL for testing (build w/o optimization, so it's probably a bit slow): http://cygwin.de/cygwin-177/new-cygwin1.dll.bz2 (md5sum: 7e07fd9eafd021697a0861c1ae4fa94e) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Cygwin slow on x64 systems
Hello, For the last couple of weeks I'm trying to identify the cause for cygwin slowdown on x64 machines which was reported by David Morgan about 6 months ago. I wrote a little bash script which prints the result of 'date -s' to a file in a loop and then counts the number of times the same second appears in that file. I used this script to test all available cygwin revisions snapshots (which I downloaded from ftp://www.fruitbat.org/pub/cygwin/circa/index.html) for cygwin version 1.5.19-4. I was able to identify the exact change which introduce the slowdown. With my test script for cygwin version 1.5.19-4, snapshot timestamp 1142005204 I'm able to get ~40 lines/second, but with the same version, snapshot timestamp 1142338816 the result is ~18 lines/second. Using cvsps I was able to generate a patchset which contains all the changes between those 2 revisions. I then applied the changes one by one and built cygwin1.dll for each change, then I ran my test script again for each cygwin1.dll version and I found that the change to winsup/cygwin/dcrt0.cc from '2006/03/12 23:57:03' introduce this issue. The log for this change is : * dcrt0.cc (dll_crt0_0): Call sigproc_init during init startup. (_dll_crt0): Don't worry about sync_startup. Just wait for sigthread here. This change includes 2 different sub-changes : 1. Moving the call to sigproc_init from dll_crt0_1 function to dll_crt0_0 - which doesn't affect performance. 2. a. Moving the call to wait_for_sigthread from dll_crt0_1 to _dll_crt0 which calls dll_crt0_1. b. Deleting the call to WaitForSingleObject, i.e. : "Don't worry about sync_startup" I can confirm that the 2nd sub-change is the cause for the slowdown. Any help will be appreciated. Thank you, Sagi. -- Sagi Ben-Akiva - sagi at graphtech dot co dot il GraphTech Computer Systems -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: setup.exe crashes when downgrading gcc4
On Fri, Aug 27 2010, Andy Koppe wrote: > > So I select "4.3.4-3", and then "next". Then setup.exe crashes with this > > error: > > An unhandled win32 exception occurred in setup.exe [1672]. > > I wasn't able to reproduce this. Were you using the then-latest > version 2.712 of setup.exe? You could also try 2.721, which has just > been uploaded. Hello Andy, It was the version 2.712. I've just tried 2.721 and the same crash happens. > I take it you didn't click on the Exp or Keep radio buttons? Did you > downgrade all three packages you mentioned? Did it crash straight > away, after some delay, or only when it got to the 'Progress' page? It crashes right after the opening of the progress page. It crashes, when I try to downgrade at least one of the 3 packages. > Another thing to try is to simply click Next without changing > anything, because setup automatically downgrades you from any > experimental packages anyway, unless you tell it otherwise using Exp > or Keep. When trying this, it crashes too. New results: - when clicking on the Exp radio button, I was able to uninstall these 3 packages without crash - when trying to install gcc4 (any version) again, setup.exe crashes - when trying to uninstall gcc3, setup.exe crashes - it seems, that it crashes now, whatever I do... I attach the output of cygcheck -srv, hoping that it helps finding a solution... Peter -- Contact information: http://pmrb.free.fr/contact/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin Digest 27 Aug 2010 19:30:22 -0000 Issue 7179
Hello again, I am sorry to bother you again with this, but dbaltex still doesn't work: peter [~] dhajage2 $ dblatex essai.xml /usr/lib/python2.6/site-packages/dbtexmf/dblatex/grubber/util.py:8: DeprecationW arning: the md5 module is deprecated; use hashlib instead import md5 Build the book set list... Build the listings... XSLT stylesheets DocBook - LaTeX 2e (0.3) === Build essai.pdf This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) kpathsea: Running mktexfmt pdflatex.fmt /bin/mktexfmt: line 333: /texconfig/tcfmgr: No such file or directory fmtutil: config file `fmtutil.cnf' not found. I can't find the format file `pdflatex.fmt'! pdflatex failed Could not run pdflatex. Unexpected error occured Is there another option? david > -- Message transféré -- > From: Csaba Raduly > To: cyg...@cygwin.com > Date: Fri, 27 Aug 2010 10:59:25 +0200 > Subject: Re: problem with dblatex > On Fri, Aug 27, 2010 at 10:46 AM, David Hajage wrote: >> Is there a solution to tell cygwin to not use texlive >> version of pdflatex? > > Put this in your .bashrc: > > PATH=`echo $PATH | tr ":" "\n" | grep -v texlive2007 | tr "\n" ":" > > Note1: substitute "texlive2007" above with the proper directory name (not > path) > > > -- > Life is complex, with real and imaginary parts. > "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus > Torvalds > "People disagree with me. I just ignore them." -- Linus Torvalds > > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: SEGV in gcc 4.3.4 on cygwin 1.7.6-1
Thanks. This bug seems to be related since in my case there were also some options that were present more than once. I got around the problem by tweaking the configuration parameters. > On 27/08/2010 09:31, Csaba Raduly wrote: > > > How odd. It seems to crash only with that exact number of parameters. > > This sounds a lot like a bug I fixed a while ago. Should be OK in 4.5.0 > > http://gcc.gnu.org/ml/gcc-patches/2010-05/msg02263.html > > >cheers, > DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
