Re: 1.7 fork errors in Win7
Eliot, I got some time to re-read the rebase read me file this weekend and I'm now a bit more uncertain about your recommendation. If I understand correctly, you're saying I should mark ALL (almost at least, I don'tknow what not to yet) dlls, exes and sos as not ASLR compatible and then rebase with enough space between them so they are separate enough that they can be loaded in the same place by Window's loader without conflict. So, it seems we are simply taking the Windows loader out of the business of loading DLLs et all in the same memory location for all concurrent processes. If so, then: How do I figure out what binaries don't need to be rebased and peflaged? Trial and error? Why not use rebaseall and peflagsall instead? Thanks, Luis P Caamano Atlanta, GA USA On Wed, Dec 2, 2009 at 3:41 PM, Luis P Caamano wrote: On Wed, Dec 2, 2009 at 3:29 PM, Eliot Moss, wrote Date: Wed, 02 Dec 2009 11:43:44 -0500 Subject: Re: 1.7 fork errors in Win7 Luis P Caamano wrote: I'm running 1.7.0-67 on Windows 7 64 bit: $ uname -v 2009-11-27 15:38 and I'm getting sporadic for errors like this one: $ svn commit -m xxx yyy 2 [main] svn 5924 fork: child -1 - died waiting for longjmp before initialization, retry 0, exit code 0xC005, errno 11 svn: Commit failed (details follow): svn: Can't create tunnel: Resource temporarily unavailable This is not limited to svn of course, just one example. My cygwin environment is very usable as these are not that frequent but every time I'm thinking all is well, one of these comes up to remind me it's not. Is this a known issue? Is there any information I can provide to help debug and fix this? Is there anything I can do on my end to investigate the issue? Thanks in advance for all your work on 1.7, it's looking good. This smells like collisions with Windows dll's, which can happen somewhat randomly because of Address Space Randomization in recent Windows OSs. What fixes it for me is suitably rebasing all cygwin dll, so, and exe files appropriately. Details: /bin/rebase -d -b 0x6100 -o 0x2 -v -T file with list of dll and so files rebase.out and /bin/peflags -d0 -v -T file with list of dll and so files peflags-d.out /bin/peflags -t0 -v -T file with list of exe files peflags-t.out Corinna and others say that this should not be necessary, but I get problems with certain forking programs if I don't do it. Note the -o flag, which makes sure that items are far enough apart that certain metadata does not cause problems. Do read up on how to use rebase and peflags! They need to be called from ash, not bash, since otherwise soe of the dll's will be open. Also, I have found the need to drop one or two specific files from the list of *all* so, dll, and exe files that I build with find, so do check the output, etc. Regards -- Eliot Moss -- 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
1.7 fork errors in Win7
I'm running 1.7.0-67 on Windows 7 64 bit: $ uname -v 2009-11-27 15:38 and I'm getting sporadic for errors like this one: $ svn commit -m xxx yyy 2 [main] svn 5924 fork: child -1 - died waiting for longjmp before initialization, retry 0, exit code 0xC005, errno 11 svn: Commit failed (details follow): svn: Can't create tunnel: Resource temporarily unavailable This is not limited to svn of course, just one example. My cygwin environment is very usable as these are not that frequent but every time I'm thinking all is well, one of these comes up to remind me it's not. Is this a known issue? Is there any information I can provide to help debug and fix this? Is there anything I can do on my end to investigate the issue? Thanks in advance for all your work on 1.7, it's looking good. -- Luis P Caamano Atlanta, GA USA cygcheck.out Description: Binary data -- 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: 1.7 fork errors in Win7
On Wed, Dec 2, 2009 at 3:29 PM, Eliot Moss, wrote Date: Wed, 02 Dec 2009 11:43:44 -0500 Subject: Re: 1.7 fork errors in Win7 Luis P Caamano wrote: I'm running 1.7.0-67 on Windows 7 64 bit: $ uname -v 2009-11-27 15:38 and I'm getting sporadic for errors like this one: $ svn commit -m xxx yyy 2 [main] svn 5924 fork: child -1 - died waiting for longjmp before initialization, retry 0, exit code 0xC005, errno 11 svn: Commit failed (details follow): svn: Can't create tunnel: Resource temporarily unavailable This is not limited to svn of course, just one example. My cygwin environment is very usable as these are not that frequent but every time I'm thinking all is well, one of these comes up to remind me it's not. Is this a known issue? Is there any information I can provide to help debug and fix this? Is there anything I can do on my end to investigate the issue? Thanks in advance for all your work on 1.7, it's looking good. This smells like collisions with Windows dll's, which can happen somewhat randomly because of Address Space Randomization in recent Windows OSs. What fixes it for me is suitably rebasing all cygwin dll, so, and exe files appropriately. Details: /bin/rebase -d -b 0x6100 -o 0x2 -v -T file with list of dll and so files rebase.out and /bin/peflags -d0 -v -T file with list of dll and so files peflags-d.out /bin/peflags -t0 -v -T file with list of exe files peflags-t.out Corinna and others say that this should not be necessary, but I get problems with certain forking programs if I don't do it. Note the -o flag, which makes sure that items are far enough apart that certain metadata does not cause problems. Do read up on how to use rebase and peflags! They need to be called from ash, not bash, since otherwise soe of the dll's will be open. Also, I have found the need to drop one or two specific files from the list of *all* so, dll, and exe files that I build with find, so do check the output, etc. Regards -- Eliot Moss Thanks Eliot, I'll try that later tonight and I'll report back. I'm also getting this kind of error from gvim (that I built myself to add python to it): 2 [main] vim 7580 C:\cygwin\usr\local\bin\vim.exe: *** fatal error - unable to remap \\?\C:\cygwin\lib\gtk-2.0\2.10.0\loaders\cygpixbufloader-xpm.dll to same address as parent: 0x3F != 0x5B 2 [main] gvim 7844 fork: child 7580 - died waiting for dll loading, errno 11 After that, gvim hangs and I have to kill it. That seems like the same issue and it could also be solved with a proper rebase, right? -- Luis P Caamano Atlanta, GA USA -- 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: Bash process remains after I close rxvt in certain ways
The problem I've been having for quite a while now may or may not be related to this but it's indeed similar. I start XWin from a batch file that also starts a gnome-terminal. I always have to kill the gnome-pty-helper.exe process in order to be able to open more terminals. The point where it hangs varies from just creating the second terminal to up to maybe the 7th. I've never seen it go beyond that before needing to kill the helper process. This issue made me start a Sysinternals's Process Explorer window as a pre-requisite to starting XWin and the gnome-terminals. I now start XWin and then look in the process explorer window for the gnome-pty-helper process, kill it and then watch the rest of the terminals come up. If I look at the threads in the gnome-pty-helper.exe process, I find two threads, one doing about 92 context switches per second with a start address at 'gnome-pty-helper.exe+0x1000' and the other one is at cygwin1.dll!toascii+0x15d0. This second one is a pretty common address I see when I get cygwin runaway processes using 100% CPU but that's a different story I think (or maybe not?) I've killed that thread only to see if it would help but it looks like something is waiting for the process to finish because things only keep rolling after I kill the process not just the thread. Mind you, sometimes it doesn't happen right away, that is, the second terminal starts find even though the gnome-pty-helper.exe is still there. The other relatead issue is that when I exit the last bash shell in the gnome-terminals, the gnome-terminal.exe process doesn't go away either and I have to kill that one too. Well, actually, Process Explorer says the the gnome-terminal.exe process is a child of a bash.exe process as expected I guess but there are other bash shells, those in each gnome terminal window or tab, which where started by gnome-terminal. They show up as siblings and not as children though. When I kill the gnome-terminal.exe process, the bash.exe parent process goes away by itself. It all seems related to gnome-terminal and the related supporting gnome packages and not to bash itself, which is basically why I haven't posted anything about this here but this time it seems at least somebody might tell me that indeed it's not and point in a more hopeful direction. Thanks -- Luis P Caamano Atlanta, GA USA On 13 Nov 2006 15:08:48 -, [EMAIL PROTECTED] Igor Peshansky wrote: According to Eric Lilja on 11/12/2006 12:52 PM: I recently upgraded to a dual core machine which made me use the windows task manager alot. That's when I noticed that if I close the rxvt window by pressing 'x' in the top right corner (or doing alt-f4, I never do this, just tried it now to see what happened) the rxvt process is terminated and the window disappears but the underlying bash process is still running (without a visible window), consuming ~3.5 MB of memory and 0 cpu time according to the task manager. So far, no one has found a good way for a cygwin process killed by Alt-F4 (or the X button) to treat that as a SIGHUP and pass that information on to all of its children processes. So, by killing rxvt abruptly, you are indeed stranding bash as a zombie process. If I exit rxvt by typing exit, the bash process is terminated too. Actually, typing exit will exit bash, not rxvt; but when rxvt realizes that all of its children processes have exited, it exits as well. Can I do something so the bash process is always terminated properly no matter how I close the rxvt window? Submit a patch to make cygwin processes recognize Alt-F4 as a SIGHUP that needs to be passed to their children? Or possibly even a patch such that when a controlling pty terminal is closed, all children (such as bash) reading from that pty get an end-of-input (possibly a SIGPIPE) when trying to read from the disappearing terminal? Actually, it's not the Cygwin processes that need that feature, but the W11 library. When rxvt is closed via the 'X' button or Alt-F4, Windows sends it the WM_QUIT message, which ought to be handled properly in the library as application exit (and thus send SIGHUP to all immediate children). This is done by the Cygwin console already, so it may simply be a matter of copying/pasting some code... Is there misconfiguration on my end or should I simply get in the habit of always using exit to close rxvt? For now, that is the best course of action. -- 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: Bash process remains after I close rxvt in certain ways
The problem I've been having for quite a while now may or may not be related to this but it's indeed similar. I start XWin from a batch file that also starts a gnome-terminal. I always have to kill the gnome-pty-helper.exe process in order to be able to open more terminals. The point where it hangs varies from just creating the second terminal to up to maybe the 7th. I've never seen it go beyond that before needing to kill the helper process. This issue made me start a Sysinternals's Process Explorer window as a pre-requisite to starting XWin and the gnome-terminals. I now start XWin and then look in the process explorer window for the gnome-pty-helper process, kill it and then watch the rest of the terminals come up. If I look at the threads in the gnome-pty-helper.exe process, I find two threads, one doing about 92 context switches per second with a start address at 'gnome-pty-helper.exe+0x1000' and the other one is at cygwin1.dll!toascii+0x15d0. This second one is a pretty common address I see when I get cygwin runaway processes using 100% CPU but that's a different story I think (or maybe not?) I've killed that thread only to see if it would help but it looks like something is waiting for the process to finish because things only keep rolling after I kill the process not just the thread. Mind you, sometimes it doesn't happen right away, that is, the second terminal starts find even though the gnome-pty-helper.exe is still there. The other relatead issue is that when I exit the last bash shell in the gnome-terminals, the gnome-terminal.exe process doesn't go away either and I have to kill that one too. Well, actually, Process Explorer says the the gnome-terminal.exe process is a child of a bash.exe process as expected I guess but there are other bash shells, those in each gnome terminal window or tab, which where started by gnome-terminal. They show up as siblings and not as children though. When I kill the gnome-terminal.exe process, the bash.exe parent process goes away by itself. It all seems related to gnome-terminal and the related supporting gnome packages and not to bash itself, which is basically why I haven't posted anything about this here but this time it seems at least somebody might tell me that indeed it's not and point in a more hopeful direction. Thanks -- Luis P Caamano Atlanta, GA USA On 13 Nov 2006 15:08:48 -, [EMAIL PROTECTED] Igor Peshansky wrote: According to Eric Lilja on 11/12/2006 12:52 PM: I recently upgraded to a dual core machine which made me use the windows task manager alot. That's when I noticed that if I close the rxvt window by pressing 'x' in the top right corner (or doing alt-f4, I never do this, just tried it now to see what happened) the rxvt process is terminated and the window disappears but the underlying bash process is still running (without a visible window), consuming ~3.5 MB of memory and 0 cpu time according to the task manager. So far, no one has found a good way for a cygwin process killed by Alt-F4 (or the X button) to treat that as a SIGHUP and pass that information on to all of its children processes. So, by killing rxvt abruptly, you are indeed stranding bash as a zombie process. If I exit rxvt by typing exit, the bash process is terminated too. Actually, typing exit will exit bash, not rxvt; but when rxvt realizes that all of its children processes have exited, it exits as well. Can I do something so the bash process is always terminated properly no matter how I close the rxvt window? Submit a patch to make cygwin processes recognize Alt-F4 as a SIGHUP that needs to be passed to their children? Or possibly even a patch such that when a controlling pty terminal is closed, all children (such as bash) reading from that pty get an end-of-input (possibly a SIGPIPE) when trying to read from the disappearing terminal? Actually, it's not the Cygwin processes that need that feature, but the W11 library. When rxvt is closed via the 'X' button or Alt-F4, Windows sends it the WM_QUIT message, which ought to be handled properly in the library as application exit (and thus send SIGHUP to all immediate children). This is done by the Cygwin console already, so it may simply be a matter of copying/pasting some code... Is there misconfiguration on my end or should I simply get in the habit of always using exit to close rxvt? For now, that is the best course of action. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin/X does not start after updating Cygwin1.dll to 1.5.20-1
Just FYI. I'm running 1.5.20-1, X starts fine and I'm gladly running several gnome-terminals with no problems. I also run sshd and httpd2. -- Luis P Caamano Atlanta, GA USA -- 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: Updated: cygwin-1.5.20-1
Nice, many thanks! Just FYI, the gnome-terminal now doesn't complain about updwtmpx on first start but every now and then the gnome-pty-helper seems to hang gnome-terminal.exe when creating a new tab. It's not that bad though as it only seems to happen when opening several terminals at the same time and opening a tab on them quickly. On 7/2/06, Christopher Faylor [EMAIL PROTECTED] wrote: I've made a new version of the Cygwin DLL and associated utilities available for download. As usual, a list of what has changed is below. [ snip ] Changes since 1.5.19-4: [ snip ] corinna: Implement updwtmpx. [ snip ] cgf: Rework pty master handling to avoid handle leak (thanks to Dave Korn for initial implementation). -- Luis P Caamano Atlanta, GA USA -- 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: Updated: cygwin-1.5.20-1
Nice, many thanks! Just FYI, the gnome-terminal now doesn't complain about updwtmpx on first start but every now and then the gnome-pty-helper seems to hang gnome-terminal.exe when creating a new tab. It's not that bad though as it only seems to happen when opening several terminals at the same time and opening a tab on them quickly. On 7/2/06, Christopher Faylor [EMAIL PROTECTED] wrote: I've made a new version of the Cygwin DLL and associated utilities available for download. As usual, a list of what has changed is below. [ snip ] Changes since 1.5.19-4: [ snip ] corinna: Implement updwtmpx. [ snip ] cgf: Rework pty master handling to avoid handle leak (thanks to Dave Korn for initial implementation). -- Luis P Caamano Atlanta, GA USA -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Updated: vim-7.0.035-1
On 6/23/06, Corinna Vinschen wrote: I have updated the version of vim on cygwin.com to 7.0.035-1. Thanks. Last time I had to compile from sources in order to get gvim. Is a GTK2 gvim included in 7.0.035-1 as it used to be in the 6.x series? -- Luis P Caamano Atlanta, GA USA -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: updwtmpx
Thanks for your reply Igor. Does that mean that the gnome-terminal I got from standard setup was compiled with the cygwin1.dll file from a snapshot? On 6/22/06, Igor Peshansky [EMAIL PROTECTED] wrote: On Thu, 22 Jun 2006, Luis P Caamano wrote: The latest gnome-terminal, which works nicely btw, complaints before first start that it cannot find updwtmpx in cygwin1.dll. I see that it was added back in February but I can't figure out which version includes it. http://article.gmane.org/gmane.os.cygwin.cvs/2345/match=updwtmpx+cygwin Perhaps it's in an experimental version? It's a snapshot (http://cygwin.com/faq/faq.setup.html#faq.setup.snapshots). It'll also be in 1.5.20, whenever that comes out. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac -- Luis P Caamano Atlanta, GA USA -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: updwtmpx
Thanks for the clarifications Igor. -- Luis P Caamano Atlanta, GA USA On 6/22/06, Igor Peshansky [EMAIL PROTECTED] wrote: http://cygwin.com/acronyms/#TOFU reformatted. On Thu, 22 Jun 2006, Luis P Caamano wrote: On 6/22/06, Igor Peshansky [EMAIL PROTECTED] wrote: http://cygwin.com/acronyms/#PCYMTNQREAIYR. Thanks. On Thu, 22 Jun 2006, Luis P Caamano wrote: The latest gnome-terminal, which works nicely btw, complaints before first start that it cannot find updwtmpx in cygwin1.dll. I see that it was added back in February but I can't figure out which version includes it. http://article.gmane.org/gmane.os.cygwin.cvs/2345/match=updwtmpx+cygwin Perhaps it's in an experimental version? It's a snapshot (http://cygwin.com/faq/faq.setup.html#faq.setup.snapshots). It'll also be in 1.5.20, whenever that comes out. Igor Thanks for your reply Igor. Does that mean that the gnome-terminal I got from standard setup was compiled with the cygwin1.dll file from a snapshot? First, you did not get gnome-terminal from the official Cygwin distribution, since a search for gnome-terminal on the Cygwin package search page turns up only the icons and the themes. The fact that you used Cygwin setup to install gnome-terminal doesn't really matter, since you can supply any mirror to Cygwin setup and it'll happily give you all the packages on that mirror alongside the official Cygwin packages. That means you will need to take it up with whoever provides gnome-terminal. I'm guessing it's the CygwinPorts project, and they have their own mailing lists. Since I can't find anything after a quick search of CygwinPorts about gnome-terminal requiring a snapshot, I can only assume that it's an unintentional packaging error, but Yaakov would be the person to answer that (on a CygwinPorts list). Also, a minor clarification: it was built against the snapshot *headers*, not just the snapshot cygwin1.dll, but the upshot of that is that it requires a snapshot DLL. HTH, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
updwtmpx
The latest gnome-terminal, which works nicely btw, complaints before first start that it cannot find updwtmpx in cygwin1.dll. I see that it was added back in February but I can't figure out which version includes it. http://article.gmane.org/gmane.os.cygwin.cvs/2345/match=updwtmpx+cygwin Perhaps it's in an experimental version? -- Luis P Caamano Atlanta, GA USA -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gvim fontconfig issue from clean install
What do you mean from scratch? Compiled from source? or newly installed from setup? I think you just need to follow the instructions given. Not all X apps use fontconfig. -- lpc On 6/13/06, simon godden [EMAIL PROTECTED] wrote: I installed cygwin from scratch and selected gvim. When I try to run it, I get the message: No fonts found; this probably means that the fontconfig library is not correctly configured. You may need to edit the fonts.conf configuration file. More information about fontconfig can be found in the fontconfig(3) manual page and on http://fontconfig.org Other basic x applications are working fine, as is emacs. Any ideas? -- Simon Godden -- 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/ -- 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: Updated: vim-7.0.017-1
On 12 Jun 2006 17:06:33 -, Reid Thompson [EMAIL PROTECTED] wrote: Subject: Re: Updated: vim-7.0.017-1 Luis P Caamano wrote: Well, almost. After updating I realized that gvim is not included :-( so I ended up with a vim 7.0 and a gvim 6.4, which is not that useful it seems. Had to go back to 6.4. :-( On 6/12/06, Luis P Caamano [EMAIL PROTECTED] wrote: On 6/12/06, Corinna Vinschen [EMAIL PROTECTED] wrote: I have updated the version of vim on cygwin.com to 7.0.017-1. This is the long awaited vim 7.0, latest patchlevel 17. Cygwin Vim still builds from the vanilla sources. Thank you -- Luis P Caamano Atlanta, GA USA Build it from source... If anyone can advise how to 'fix' the caveat listed at the bottom, I'd appreciate it. cd /usr/src mkdir vim cd vim svn co https://svn.sourceforge.net/svnroot/vim/vim7 cd vim7 ./configure --enable-rubyinterp --enable-cscope --enable-fontset --with-features=huge make make install only one caveat -- when invoking gvim, you have to pass the -f parameter, otherwise you will get: gvim: Fatal IO error 128 (Transport endpoint is not connected) on X server :0.0. thanks, reid Well, I did that last night, build from sources. I did not have the transport error you mentioned but I had trouble make it build with gtk2. Turns out I needed to install the pkg-config cygwin package for vim's configure to find gtk 2.2. Without it, configure was only finding gtk-config, which was giving it gtk 1.2 libs. I'm sorry I cannot help much with your error. All I can say is that it seems you're missing something in cygwin. For the record, here's the configure cmd I ran (after installing pkg-config): ./configure --enable-pythoninterp --enable-cscope --enable-multibyte --enable-fontset --enable-gui=auto --with-features=huge --with-x -- Luis P Caamano Atlanta, GA USA -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Updated: vim-7.0.017-1
On 6/12/06, Corinna Vinschen [EMAIL PROTECTED] wrote: I have updated the version of vim on cygwin.com to 7.0.017-1. This is the long awaited vim 7.0, latest patchlevel 17. Cygwin Vim still builds from the vanilla sources. Thank you -- Luis P Caamano Atlanta, GA USA -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Updated: vim-7.0.017-1
Well, almost. After updating I realized that gvim is not included :-( so I ended up with a vim 7.0 and a gvim 6.4, which is not that useful it seems. Had to go back to 6.4. :-( On 6/12/06, Luis P Caamano [EMAIL PROTECTED] wrote: On 6/12/06, Corinna Vinschen [EMAIL PROTECTED] wrote: I have updated the version of vim on cygwin.com to 7.0.017-1. This is the long awaited vim 7.0, latest patchlevel 17. Cygwin Vim still builds from the vanilla sources. Thank you -- Luis P Caamano Atlanta, GA USA -- Luis P Caamano Atlanta, GA USA -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin Digest 31 May 2006 18:20:53 -0000 Issue 4986
On Tue, 30 May 2006 22:39:24 -0700, David Christensen [EMAIL PROTECTED] wrote: Subject: RE: 200 GB drive has room but gzip indicates No space left on device Cygwin: I put the 200 GB drive into an XP box and ran Cygwin df -- same result. Cygwin utilities, including df, work fine a 250 GB drive in the same XP box. I must assume that the 200 GB disk is corrupted, or is failing. David, what filesystem is on the disk? This is a common error on big disks with only one Linux ext3 filesystem using a default number of inodes with a lot of small files in it. The error happens because the filesystem runs out of inodes before it runs out of space due to the large number of small files. If you have an NTFS in it, something similar might be happening. A quick test to verify is to remove one file and then create a big one or something like that. I don't know if that's the problem but it's just one more thing to think about. -- Luis P Caamano Atlanta, GA USA -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin Digest 28 May 2006 16:43:42 -0000 Issue 4979
On 28 May 2006 16:43:42 -, Larry Hall wrote: Luis P Caamano wrote: Is a cygwin binary of Vim 7.0 coming soon? Not immediately, no. The maintainer is currently away. On her return, I'm sure it's something she will look at. Good to know. Thanks for your reply. -- Luis P Caamano Atlanta, GA USA -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
vim7?
Is a cygwin binary of Vim 7.0 coming soon? -- Luis P Caamano Atlanta, GA USA -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin gnome-terminal pty error
I haven't had a chance to get back to it and I'm still stuck using a boat load of xterms all over the place instead of the nice tabs I could have had gnome-terminal work as expected. That's the thing about cygwin ... you get really weird errors that not many people have seen before. Oh wait. Now that I read your email again (and carefully) I see you haven't seen my newer email. After the last update, I'm now getting a different behavior. I'm not getting the pty errors, which is what made me install cygserver btw, (which somehow got rid of my fork problems, that's another story though) but the gnome terminal doesn't do anything. That is, before, at least the menus did work (what gnome-terminal really is) but the canvas was blank. Now not even the menus work. I'll get back to it eventually ... unless you find a solution before me. One thing seems certain though: nobody is using gnome-terminal. On 4/19/06, Peter [EMAIL PROTECTED] wrote: Luis P Caamano lcaamano at gmail.com writes: Hello, I've installed gnome-terminal from the sunsite.dk/projects/cygwinports site with no errors. Unfortunately, when I run gnome-terminal from an xterm I get the error below: - $ gnome-terminal ** (gnome-terminal:3608): WARNING **: Error setting PTY size: Invalid argument. ** (gnome-terminal:3608): WARNING **: Error reading PTY size, using defaults: Invalid argument. ** (gnome-terminal:3608): WARNING **: Error reading PTY size, using defaults: Invalid argument. ** (gnome-terminal:3608): WARNING **: Error setting PTY size: Invalid argument. ** (gnome-terminal:3608): WARNING **: Error reading PTY size, using defaults: Invalid argument. - --- Even I am having the same problem. My Terminal session just hangs there without returning the command prompt. Have you been able to fix this? Or did someone else have a solution to this problem? I am guessing it is some env setting in cygwin but cannot figure out what. Thanks, Peter [EMAIL PROTECTED] -- 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/ -- Luis P Caamano Atlanta, GA USA -- 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: when is using cygserver recommended? (thx)
-- Forwarded message -- From: [EMAIL PROTECTED] (J. David Boyd) To: cygwin@cygwin.com Date: Fri, 07 Apr 2006 16:29:59 -0400 Subject: Re: when is using cygserver recommended? (thx) Christopher Faylor [EMAIL PROTECTED] writes: In that case, my previous reply is even more pertinent; especially given that Igor mentioned that the problem has nothing to do with cygserver. cgf Strange then, that my 'fork' problem has now gone away, after adjusting my cygserver.conf file Dave I don't know if it fixes it or not but I can tell you that I started using cygserver perhaps a couple months ago and after changing that variable, I've never seen the fork problem again. However, I'm not completely sure but I think that the chain of events was like this: 1- no fork problems 2- added cygserver for different reasons 3- got fork problems 4- edited cygserver.conf 5- no fork problems Right now, although I understand that fork problem, I do not understand its cause or why the cygserver.conf change fixed it. I think the reason I edited that file was because I got the impression that using cygserver is what caused my fork problems. It seems though that people are getting the fork problems even when not using cygserver. I concluded that I needed to research cygserver a lot more to understand what's going. One day ... One thing is certain, though. I'm very glad I don't see the fork problems anymore. -- Luis P Caamano Atlanta, GA USA -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: fork problem
On 6 Apr 2006 03:44:22 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: fork problem 120469 by: [EMAIL PROTECTED] (J. David Boyd) I started using cygserver and edited its config file to use 310 procs instead of 62. In /etc/cygserver.conf, I edited the following: # kern.srv.process_cache_size: No. of concurrent processes which can be handled # by Cygserver concurrently. # Default: 62, Min: 1, Max: 310, command line option -p, --process-cache kern.srv.process_cache_size 310 I also set the CYGWIN var like this: $ echo $CYGWIN server ntsec I believe I set that variable in the Windows XP environment, that is, System Properties dialog, Advance Tab, Environment Variables button. Let me check ... yes, I did. I don't remember how to set up cygserver to start as a service but the doc was very clear. You, of course, need cygrunsrv to run cygserver. Here's the output of ps -ef: $ ps -ef UID PIDPPID TTY STIME COMMAND SYSTEM1276 1 ? 00:54:28 /usr/bin/cygrunsrv SYSTEM13801276 ? 00:54:29 /usr/sbin/cygserver SYSTEM 632 1 ? 00:54:38 /usr/bin/cygrunsrv SYSTEM1820 632 ? 00:54:38 /usr/sbin/syslog-ng SYSTEM 180 1 ? 00:54:39 /usr/bin/cygrunsrv SYSTEM 340 180 ? 00:54:39 /usr/sbin/sshd lpc3608 1 con 09:12:47 /usr/X11R6/bin/XWin lpc1016 1 con 09:12:52 /usr/bin/xterm lpc23081016 0 09:12:53 /usr/bin/bash lpc 516 1 ? 09:12:58 /usr/bin/ssh-agent lpc25363608 ? 09:14:07 /usr/bin/xterm lpc25802536 1 09:14:08 /usr/bin/ssh lpc20643608 ? 09:55:23 /usr/bin/xterm lpc35202064 2 09:55:23 /usr/bin/bash lpc2692 1 ? 10:04:22 /usr/bin/gvim lpc 3323520 2 10:07:49 /usr/bin/ps Hope that helps, -- Luis P Caamano Atlanta, GA USA -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin gnome-terminal pty error
Thanks for you reply René. I think I going to have to switch from digest to getting every email. I see you replied right away but I just got the digest today. On 19 Mar 2006 05:00:56 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: cygwin-xfree Digest 19 Mar 2006 05:00:56 - Issue 1971 -- Forwarded message -- From: René Berber [EMAIL PROTECTED] To: cygwin-xfree@cygwin.com Date: Fri, 17 Mar 2006 22:27:36 -0600 Subject: Re: cygwin gnome-terminal pty error Luis P Caamano wrote: How is gnome-terminal hanging? You see the process but no window? or as before, a window with no shell prompt? -- René Berber Before I'd see a fully functional gnome-terminal, the shell, but no prompt. The menus and everything else would work as expected. Now I see just a window but the menu doesn't even show up. Worse, once I run gnome-terminal, I cannot kill it and XWin hangs trying to fork new xterm from the XWin menu. I have to use the Windows task manager to kill all the XWin stuff and then restart XWin again. IOW, after gnome-terminal is up and hung, if I right click the X to start more xterms, they don't show up and ps -ef in cygwin shows one XWin process for every time I try to start a new local xterm. At this point in time, I'd just like to find somebody that is using a gnome-terminal in cygwin so I can tell if it's my environment or if the problem is the package itself. I sent an email to Yaakov but I guess he didn't see in the sea of emails he probably gets every day. -- Luis P Caamano Atlanta, GA USA -- 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 gnome-terminal pty error
I updated cygwin with the latest vte package and now instead of the pty error, gnome-terminal just hangs with no error. I'm installing packages from kernel.org and from sunsite.dk. Is it possible that the mix of packages is the problem? The only gnome package I selected was the gnome-terminal package, which then selected its pre-requisites. Could it be that I missing something? I'm running with CYGWIN=server ntsec. Could it be that cygserver is not configured properly? Finally, is anybody running gnome-terminal on cygwin? I'd appreciate any hint or clue about this. Anything ... Thanks On 2/22/06, Luis P Caamano [EMAIL PROTECTED] wrote: Hello, I've installed gnome-terminal from the sunsite.dk/projects/cygwinports site with no errors. Unfortunately, when I run gnome-terminal from an xterm I get the error below: - $ gnome-terminal ** (gnome-terminal:3608): WARNING **: Error setting PTY size: Invalid argument. ** (gnome-terminal:3608): WARNING **: Error reading PTY size, using defaults: Invalid argument. ** (gnome-terminal:3608): WARNING **: Error reading PTY size, using defaults: Invalid argument. ** (gnome-terminal:3608): WARNING **: Error setting PTY size: Invalid argument. ** (gnome-terminal:3608): WARNING **: Error reading PTY size, using defaults: Invalid argument. I do get a gnome-terminal window with no shell prompt (white background). The menu seems to work fine as I can bring the edit current profile dialog. Anybody using gnome-terminal in cygwin or seen this error? Perhaps I have a package incompatibility? I initially installed from mirrors.kernel.org and then added the sunsite.dk, selected gnome-terminal only, and it automatically selected a bunch of dependencies. So far google haven't revealed any clues. Can anybody provide me with some hints or clues that would help solve this problem? Any help is appreciated, thanks. -- Luis P Caamano Atlanta, GA USA -- Luis P Caamano Atlanta, GA USA -- 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: Test release available: apache2-2.2.0-1
On 3/7/06, Max Bowsher [EMAIL PROTECTED] wrote: * mod_proxy and its sub-modules are now included in the build, by user request. Thank you!! * mod_ssl is now included in the build. I haven't received any user requests for this one, but I figure it's popular enough that someone will definitely want it eventually. Wise choice. -- Luis P Caamano Atlanta, GA USA -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
No mod_proxy in apache2
I just installed the new apache2 package using cygwin setup. After configuring, starting and testing the server I realized that mod_proxy is not included in the install. Unfortunately, that mod_proxy and mod_rewrite were the reason I thought of installing it. I've just thrown the towel after a few hours of googling around have not produced any hints. Are there any plans to include it by default? If not, are there any instructions on how to compile apache2 to include mod_proxy? -- Luis P Caamano Atlanta, GA USA -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
