src/winsup/cygwin ChangeLog dtable.cc
CVSROOT:/cvs/src Module name:src Changes by: c...@sourceware.org 2013-12-04 17:55:17 Modified files: winsup/cygwin : ChangeLog dtable.cc Log message: * dtable.cc (dtable::find_unused_handle): When extending, always make sure that there is a NOFILE_INCR chunk following the free fd. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.6275r2=1.6276 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/dtable.cc.diff?cvsroot=srcr1=1.275r2=1.276
Re: fix off-by-one in dup2
On Wed, Dec 04, 2013 at 01:04:08PM +0100, Corinna Vinschen wrote: On Dec 4 12:36, Corinna Vinschen wrote: On Dec 4 10:32, Corinna Vinschen wrote: Hi guys, [...etc...] The problem is still present in the current sources. [...] Ouch, ouch, ouch! I tested the wrong DLL. Actually current CVS fixes this problem. Duh. Sorry for the confusion. One question, though. Assuming start is == size, then the current code in CVS extends the fd table by only 1. If that happens often, the current code would have to call ccalloc/memcpy/cfree a lot. Wouldn't it in fact be better to extend always by at least NOFILE_INCR, and to extend by (1 + start - size) only if start is size + NOFILE_INCR? Something like size_t extendby = (start = size + NOFILE_INCR) ? 1 + start - size : NOFILE_INCR; ? Sorry again. Fortunately it's my WJM week... I don't think it is a common occurrence for start = size. It is usually done when something like bash dup2's stdin/stdout/stderr to a high fd. Howeer, I'll check in something which guarantees that there is always a NOFILE_INCR entries free after start. cgf
Re: fix off-by-one in dup2
On Dec 4 12:00, Christopher Faylor wrote: On Wed, Dec 04, 2013 at 01:04:08PM +0100, Corinna Vinschen wrote: On Dec 4 12:36, Corinna Vinschen wrote: On Dec 4 10:32, Corinna Vinschen wrote: Hi guys, [...etc...] The problem is still present in the current sources. [...] Ouch, ouch, ouch! I tested the wrong DLL. Actually current CVS fixes this problem. Duh. Sorry for the confusion. One question, though. Assuming start is == size, then the current code in CVS extends the fd table by only 1. If that happens often, the current code would have to call ccalloc/memcpy/cfree a lot. Wouldn't it in fact be better to extend always by at least NOFILE_INCR, and to extend by (1 + start - size) only if start is size + NOFILE_INCR? Something like size_t extendby = (start = size + NOFILE_INCR) ? 1 + start - size : NOFILE_INCR; ? Sorry again. Fortunately it's my WJM week... I don't think it is a common occurrence for start = size. It is usually done when something like bash dup2's stdin/stdout/stderr to a high fd. Howeer, I'll check in something which guarantees that there is always a NOFILE_INCR entries free after start. That might be helpful. Tcsh, for instance, always dup's it's std descriptors to the new fds 15-19. If it does so in this order, it would have to call extend 5 times. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpbzJcH0cDuZ.pgp Description: PGP signature
Re: fix off-by-one in dup2
On Wed, Dec 04, 2013 at 06:23:24PM +0100, Corinna Vinschen wrote: On Dec 4 12:00, Christopher Faylor wrote: On Wed, Dec 04, 2013 at 01:04:08PM +0100, Corinna Vinschen wrote: On Dec 4 12:36, Corinna Vinschen wrote: On Dec 4 10:32, Corinna Vinschen wrote: Hi guys, [...etc...] The problem is still present in the current sources. [...] Ouch, ouch, ouch! I tested the wrong DLL. Actually current CVS fixes this problem. Duh. Sorry for the confusion. One question, though. Assuming start is == size, then the current code in CVS extends the fd table by only 1. If that happens often, the current code would have to call ccalloc/memcpy/cfree a lot. Wouldn't it in fact be better to extend always by at least NOFILE_INCR, and to extend by (1 + start - size) only if start is size + NOFILE_INCR? Something like size_t extendby = (start = size + NOFILE_INCR) ? 1 + start - size : NOFILE_INCR; ? Sorry again. Fortunately it's my WJM week... I don't think it is a common occurrence for start = size. It is usually done when something like bash dup2's stdin/stdout/stderr to a high fd. Howeer, I'll check in something which guarantees that there is always a NOFILE_INCR entries free after start. That might be helpful. Tcsh, for instance, always dup's it's std descriptors to the new fds 15-19. If it does so in this order, it would have to call extend 5 times. dtable.h:#define NOFILE_INCR32 It shouldn't extend in that scenario. The table starts with 32 elements. cgf
Re: Please try newest snapshot (was Re: emacs-x11: new clipboard size limitation?)
Am 2013-12-03 22:10, schrieb Christopher Faylor: On Tue, Dec 03, 2013 at 04:56:27PM +, Jon TURNEY wrote: Tried bisecting through the X server versions for the past 6 months, and it seems that this problem first appears in X server 1.14.3-2 (As an aside, it's probably relevant to the recent discussion, that I can't find the thread for, about how many previous versions we should keep around that it's not possible to do this bisection without 'Secret Knowledge' at the moment) This does contain a few clipboard changes, and in particular it changes the way the messages get processed so we will return to the select() more often (after each stage of the conversion operation), which it looks like it could be incorrect sometimes, but I'd expect this to cause unneeded blocking (waiting in select() for a message which has already been placed on the event queue by XPending() rather than the observed behaviour. Anyhow, I guess I need to look at this some more... Talking about wndproc.c, it only checks iReturn for being 0. After that, we don't really know which value it has, we only know that FD_ISSET(iConnNumber, fdsRead) returns 0. The value of iReturn should be printed in the debug output at line 133. It's 0 when I inspect it with the debugger, but yes, I'll change that. What kind of object is the iConnNumber descriptor? Pipe? Fifo? Socket? /dev/windows? We really need a simple testcase without the X and emacs overhead... It's a socket connected to the X server. I added an ugly hack to work around this symptom in the latest cygwin. It shouldn't have any big impact on anything but this particular scenario but I would appreciate it if people downloaded today's snapshot and verified that things are still working ok. I plan on addressing the actual problem for Cygwin 1.7.28. Hi, the nightly snapshot does not seem to do me any good with regard to the clipboard problem. I performed the following test, and I hope this is what you had in mind: - make sure all Cygwin processes have terminated - rename /bin/cygwin1.dll to /bin/cygwin1.dll.backup - copy the nightly snapshot of 2013-12-04 to /bin and rename it cygwin1.dll - rename /bin/XWin.exe (the test version mentioned by Jon) to /bin/XWin.exe.test - rename /bin/XWin.exe.backup (the stock version that came with my last update) to /bin/XWin.exe A quick test shows that trying to copy approx. two printed pages worth of ASCII text from an Emacs buffer to LibreOffice Writer still triggers the clipboard failure. If I revert the changes above, i.e. reactivate the stock cygwin1.dll (1.7.25) and Jon's XWin test version, the clipboard works again. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- 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: 32/64 issue building native 32-bit Cygwin from CVS
Christopher Faylor writes: On Tue, Dec 03, 2013 at 05:03:56PM +, Mark Geisert wrote: I'm running into this issue when building winsup/lsaauth. My autoconf foo is weak but it appears the configure.ac wants to use 64-bit mingw tools even on this 32-bit build. There was a similar issue in winsup/utils but recently that was fixed elsewhere and picked up by my very recent 'cvs update'. Both versions of the compiler are needed for lsaauth. With that knowledge and a couple more packages installed, I was able to build 32-bit cygwin1.dll from CVS without further issues. I don't recal any fixes like this for winsup/utils though. I misread what cvs was telling me about my own local update there, now unneeded. Deficient cvs foo there too. Sorry for the noise. Thanks for the leads, ..mark -- today's gmane Captcha: groggy -- 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: Problem with command substitution in mksh shell after upgrading to Cygwin 1.7.26
On Dec 4 03:22, PRIKHODKO, GEORGE wrote:
Hi,
After upgrading to Cygwin to 1.7.26 the commands:
print $(getIP)
print $(ipconfig | grep IPv4 Address | sort | head -1 | cut -d : -f 2 \
| sed -e s/ *\\([0-9.]*\\).*/\\1/)
in the following script
#!/usr/bin/ksh
cv=$(uname -r)
cv=${cv%\(*}
cygcheck -s -v -r cygcheck_$cv.out
exec test_$cv.log 21
set -xv
getIP() {
ipconfig | grep IPv4 Address | sort | head -1 | cut -d : -f 2 \
| sed -e s/ *\\([0-9.]*\\).*/\\1/
}
#
# the following four commands should print IP address 4 times
#
getIP
print $(getIP)
ipconfig | grep IPv4 Address | sort | head -1 | cut -d : -f 2 \
| sed -e s/ *\\([0-9.]*\\).*/\\1/
print $(ipconfig | grep IPv4 Address | sort | head -1 | cut -d : -f 2 \
| sed -e s/ *\\([0-9.]*\\).*/\\1/)
exit
started to produce incorrect results.
test_1.7.26.log shows instead of IP address a whole output of ipconfig is
printed for these lines.
/usr/bin/ksh, used in the script, is a symbolic link to /usr/bin/mksh
Please, let me know if you need more info to research the problem.
No, thank you. I could track down the culprit of the problem.
I don't have a fix yet, but it will be fixed in 1.7.27, which
will be due really soon.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgp5ztgXGQl4D.pgp
Description: PGP signature
emacs won't run
Hello. Since a bit, emacs won't start under X: no error, no message, nothing. It just starts and exits after a while without doing anything. I can run emacs -nw fine. How can I diagnose this? Is there any log I can look into? Any utility? bye Thanks av. -- 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: emacs won't run
Il 12/4/2013 10:20 AM, Andrea Venturoli ha scritto: Hello. Since a bit, emacs won't start under X: no error, no message, nothing. It just starts and exits after a while without doing anything. I can run emacs -nw fine. How can I diagnose this? Is there any log I can look into? Any utility? bye Thanks av. use strace. Regards Marco -- 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
C:\cygwin\bin\cyggcc_s-1.dll: Loaded to different address
Hello People, Cygwin seems to have become very stable recently, which is a Good Thing for me. And then I saw this one: 0 [main] perl 10672 child_info_fork::abort: C:\cygwin\bin\cyggcc_s-1.dll: Loaded to different address: parent(0x32) != child(0x3A) What could be causing it? - - Bartels -- 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: [ANNOUNCEMENT] Updated, new for 64-bit: lftp 4.4.11-1
Achim Gratz Stromeko at NexGo.DE writes: This version seems to have serious problems with the mirror command. Instead of transferring just the changed files, it seems to always want to transfer _everything_. I haven't yet looked into why this might happen, at the moment I've reverted to the previous version. The last version to work correctly is 4.4.9, I don't see anything obvious in the ChangeLog that would explain why this happens. Regards, Achim. -- 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: C:\cygwin\bin\cyggcc_s-1.dll: Loaded to different address
On 12/04/2013 12:00 PM, bartels wrote: Hello People, Cygwin seems to have become very stable recently, which is a Good Thing for me. And then I saw this one: 0 [main] perl 10672 child_info_fork::abort: C:\cygwin\bin\cyggcc_s-1.dll: Loaded to different address: parent(0x32) != child(0x3A) What could be causing it? Please note that I understand that the ad-hoc solution is to run rebaseall. Unfortunately, that is not always possible. I am looking for the cause of the problem, so that I know how to prevent it. Or is the only answer to simply run rebaseall after installation? -- bartels -- 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: Problem with command substitution in mksh shell after upgrading to Cygwin 1.7.26
On Dec 4 10:13, Corinna Vinschen wrote:
On Dec 4 03:22, PRIKHODKO, GEORGE wrote:
Hi,
After upgrading to Cygwin to 1.7.26 the commands:
print $(getIP)
print $(ipconfig | grep IPv4 Address | sort | head -1 | cut -d : -f 2 \
| sed -e s/ *\\([0-9.]*\\).*/\\1/)
in the following script
#!/usr/bin/ksh
cv=$(uname -r)
cv=${cv%\(*}
cygcheck -s -v -r cygcheck_$cv.out
exec test_$cv.log 21
set -xv
getIP() {
ipconfig | grep IPv4 Address | sort | head -1 | cut -d : -f 2 \
| sed -e s/ *\\([0-9.]*\\).*/\\1/
}
#
# the following four commands should print IP address 4 times
#
getIP
print $(getIP)
ipconfig | grep IPv4 Address | sort | head -1 | cut -d : -f 2 \
| sed -e s/ *\\([0-9.]*\\).*/\\1/
print $(ipconfig | grep IPv4 Address | sort | head -1 | cut -d : -f 2 \
| sed -e s/ *\\([0-9.]*\\).*/\\1/)
exit
started to produce incorrect results.
test_1.7.26.log shows instead of IP address a whole output of ipconfig is
printed for these lines.
/usr/bin/ksh, used in the script, is a symbolic link to /usr/bin/mksh
Please, let me know if you need more info to research the problem.
No, thank you. I could track down the culprit of the problem.
I don't have a fix yet, but it will be fixed in 1.7.27, which
will be due really soon.
The fix was already in CVS. Please try the latest snapshot from
http://cygwin.com/snapshots/, it should already contain the patch.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpw2etMSYyiC.pgp
Description: PGP signature
Re: C:\cygwin\bin\cyggcc_s-1.dll: Loaded to different address
Il 12/4/2013 12:54 PM, bartels ha scritto: On 12/04/2013 12:00 PM, bartels wrote: Hello People, Cygwin seems to have become very stable recently, which is a Good Thing for me. And then I saw this one: 0 [main] perl 10672 child_info_fork::abort: C:\cygwin\bin\cyggcc_s-1.dll: Loaded to different address: parent(0x32) != child(0x3A) What could be causing it? the base address seems very low $ rebase -si |grep cyggcc_S /usr/bin/cyggcc_s-1.dll base 0x6465 size 0x0001f000 likely some other DLL is using the expected space for cyggcc_s-1.dll in the 0x6xxx adddress range. Please note that I understand that the ad-hoc solution is to run rebaseall. Unfortunately, that is not always possible. why ? Tricky sometime, but possible always. I am looking for the cause of the problem, so that I know how to prevent it. Or is the only answer to simply run rebaseall after installation? usually yes -- bartels Marco -- 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: C:\cygwin\bin\cyggcc_s-1.dll: Loaded to different address
On 12/04/2013 01:23 PM, marco atzeri wrote: Thanks for your reply. Please note that I understand that the ad-hoc solution is to run rebaseall. Unfortunately, that is not always possible. why ? Tricky sometime, but possible always. Well, not exactly impossible, but these are production machines that belong to a customer. It is not practical to ask them to kill all processes and run rebaseall when this happens. Not to mention that there should be a tracker process reporting the issue in the first place. I am looking for the cause of the problem, so that I know how to prevent it. Or is the only answer to simply run rebaseall after installation? usually yes If that is the case, then why is it not part of the installation? I do not understand why it happens on the one Windows 7 machine and not the other. - - Bartels -- 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: C:\cygwin\bin\cyggcc_s-1.dll: Loaded to different address
Il 12/4/2013 1:35 PM, bartels ha scritto: On 12/04/2013 01:23 PM, marco atzeri wrote: I am looking for the cause of the problem, so that I know how to prevent it. Or is the only answer to simply run rebaseall after installation? usually yes If that is the case, then why is it not part of the installation? currently, it is part of the installation /etc/postinstall/autorebase.bat.done $ cygcheck -f /etc/postinstall/autorebase.bat _autorebase-000444-1 so or last rebase went wrong or something else is using cyggcc_s.dll space I do not understand why it happens on the one Windows 7 machine and not the other. MS mistery ;-) what is the outcome of rebase -si |grep cyggcc_s ? rebase -si will also provide all colliding dll's; they are marked with a * please also follow http://cygwin.com/problems.html at cygcheck -s -v -r cygcheck.out - - Bartels Marco -- 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: C:\cygwin\bin\cyggcc_s-1.dll: Loaded to different address
On Dec 4 14:53, bartels wrote: On 12/04/2013 02:11 PM, marco atzeri wrote: Il 12/4/2013 1:35 PM, bartels ha scritto: On 12/04/2013 01:23 PM, marco atzeri wrote: I am looking for the cause of the problem, so that I know how to prevent it. Or is the only answer to simply run rebaseall after installation? usually yes If that is the case, then why is it not part of the installation? currently, it is part of the installation /etc/postinstall/autorebase.bat.done $ cygcheck -f /etc/postinstall/autorebase.bat _autorebase-000444-1 Your attached cygcheck output claims something else. The rebase version should be updated to 4.4.1 as well. Okay, thanks. I missed that. It did run, I suppose: Yes, but... $ cat /etc/postinstall/autorebase.bat.done @echo off rem Postinstall scripts are always started from the Cygwin root dir rem so we can just call dash from here path .\bin;%path% dash /bin/rebaseall -p so or last rebase went wrong or something else is using cyggcc_s.dll space It is intermittent. Does that help? I do not understand why it happens on the one Windows 7 machine and not the other. MS mistery ;-) Yikes. Not really funny, but still funny. what is the outcome of rebase -si |grep cyggcc_s ? Ah, that is an interesting one: $ rebase -si rebase: failed to open rebase database /etc/rebase.db.i386: No such file or directory ...this here means that rebase never created the database, which in turn could point to rebase crashing or not having sufficient privileges on /etc. Something like that. What happens if you stop all Cygwin processes, including any service you installed, then start dash, make sure you're in /bin, and then call `./rebaseall -p'. Any helpful output? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpdlbHOKC2xm.pgp Description: PGP signature
Re: Please try newest snapshot (was Re: emacs-x11: new clipboard size limitation?)
Christopher Faylor wrote: I added an ugly hack to work around this symptom in the latest cygwin. It shouldn't have any big impact on anything but this particular scenario but I would appreciate it if people downloaded today's snapshot and verified that things are still working ok. I plan on addressing the actual problem for Cygwin 1.7.28. Tested the 32 and 64 bit DLLs doing my usual stuff. I created some scripts so I can volunteer to be DLL tester. -- 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: emacs won't run
Are you running it from the desktop from run? I discovered the same thing. One workaround that worked for me was to open a rxvt window and then run emacs from that. However, an even better workaround was simply using the w32 version and bypassing X entirely. When I changed my run shortcut to run emacs-w32 instead, it works fine. On Wed, Dec 4, 2013 at 1:20 AM, Andrea Venturoli m...@netfence.it wrote: Hello. Since a bit, emacs won't start under X: no error, no message, nothing. It just starts and exits after a while without doing anything. I can run emacs -nw fine. How can I diagnose this? Is there any log I can look into? Any utility? bye Thanks av. -- 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: Please try newest snapshot (was Re: emacs-x11: new clipboard size limitation?)
On 04/12/2013 08:09, Markus Hoenicka wrote: Am 2013-12-03 22:10, schrieb Christopher Faylor: I added an ugly hack to work around this symptom in the latest cygwin. It shouldn't have any big impact on anything but this particular scenario but I would appreciate it if people downloaded today's snapshot and verified that things are still working ok. I plan on addressing the actual problem for Cygwin 1.7.28. the nightly snapshot does not seem to do me any good with regard to the clipboard problem. I performed the following test, and I hope this is what you had in mind: There is also a bug in xwinclip which needs fixing for this test to work reliably, but it was difficult to see what that was without this fix in the cygwin DLL. - make sure all Cygwin processes have terminated - rename /bin/cygwin1.dll to /bin/cygwin1.dll.backup - copy the nightly snapshot of 2013-12-04 to /bin and rename it cygwin1.dll - rename /bin/XWin.exe (the test version mentioned by Jon) to /bin/XWin.exe.test - rename /bin/XWin.exe.backup (the stock version that came with my last update) to /bin/XWin.exe A quick test shows that trying to copy approx. two printed pages worth of ASCII text from an Emacs buffer to LibreOffice Writer still triggers the clipboard failure. If I revert the changes above, i.e. reactivate the stock cygwin1.dll (1.7.25) and Jon's XWin test version, the clipboard works again. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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: Get old fortran executable to update screen
Andrey Repin anrdaemon at yandex.ru writes: Greetings, paul! I'm using an executable compiled from a FORTRAN program When I run it from a DOS command line, I get prompts and progress updates (an iteration count that rewrites the line without scrolling the screen upward). I get none of this when I invoke the program from a cygwin bash shell. I suspect you are saying bash shell where it should be mintty terminal, which may be the actual culprit for your issue. Try running bash directly (it should start in standard Windows console) and repeat your tests. The output that should have been displayed to the user is in fact captured if I run the unix (cygwin) script command, but no guileful tricks I tried made the prompts and progress updates display in real time. I tried the script command options -f and -c OldFortramProgram.exe. I managed to get around the lack of prompts by memorizing the order of the input required of the user, and that allows the program to proceed. The progress updates would be useful, though (long run times). Sorry for my terrible english... You English seems perfectly comprehensible, Andrey. Andrey, you're partly right about mintty. If I use a DOS command line window and directly invoke bash.exe -i, I get all the prompts and iteration count updates. However, the bottleneck then becomes the script command. Even with the -f option, it buffers the text being saved before sending accumulated content to the screen in bursts. Ah well. Thanks. -- 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: C:\cygwin\bin\cyggcc_s-1.dll: Loaded to different address
On 12/04/2013 03:23 PM, Corinna Vinschen wrote: On Dec 4 14:53, bartels wrote: On 12/04/2013 02:11 PM, marco atzeri wrote: Il 12/4/2013 1:35 PM, bartels ha scritto: On 12/04/2013 01:23 PM, marco atzeri wrote: I am looking for the cause of the problem, so that I know how to prevent it. Or is the only answer to simply run rebaseall after installation? usually yes If that is the case, then why is it not part of the installation? currently, it is part of the installation /etc/postinstall/autorebase.bat.done $ cygcheck -f /etc/postinstall/autorebase.bat _autorebase-000444-1 Your attached cygcheck output claims something else. The rebase version should be updated to 4.4.1 as well. Don't think there is a mismatch: that output was Marco's, not mine. Unless I misunderstand . . . Ah, that is an interesting one: $ rebase -si rebase: failed to open rebase database /etc/rebase.db.i386: No such file or directory ...this here means that rebase never created the database, which in turn could point to rebase crashing or not having sufficient privileges on /etc. Something like that. What happens if you stop all Cygwin processes, including any service you installed, then start dash, make sure you're in /bin, and then call `./rebaseall -p'. Any helpful output? How about this; sure looks like something is wrong: ./rebaseall -p gzip: stdin: unexpected end of file Thing is that I need to work with a fixed collection of packages. The rolling release offered by the installer is fine, but not exactly suited for a controlled release to an unsuspecting user. So, perhaps I made a mistake, or there is some unfortunate combination of versions. Anyway, I will upgrade my collection bundle and try again. Unless the error message immediately rings a bell for you . . . Thanks, -- Bartels -- 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: C:\cygwin\bin\cyggcc_s-1.dll: Loaded to different address
On Dec 4 17:41, bartels wrote: On 12/04/2013 03:23 PM, Corinna Vinschen wrote: On Dec 4 14:53, bartels wrote: On 12/04/2013 02:11 PM, marco atzeri wrote: Il 12/4/2013 1:35 PM, bartels ha scritto: On 12/04/2013 01:23 PM, marco atzeri wrote: I am looking for the cause of the problem, so that I know how to prevent it. Or is the only answer to simply run rebaseall after installation? usually yes If that is the case, then why is it not part of the installation? currently, it is part of the installation /etc/postinstall/autorebase.bat.done $ cygcheck -f /etc/postinstall/autorebase.bat _autorebase-000444-1 Your attached cygcheck output claims something else. The rebase version should be updated to 4.4.1 as well. Don't think there is a mismatch: that output was Marco's, not mine. Unless I misunderstand . . . http://cygwin.com/ml/cygwin/2013-12/msg00085.html was your mail, so it's kind of hard to imagine that the attached cygcheck output was Marco's. Check the version numbers. It's _autorebase-000425-1 and rebase-4.4.0-1 in the cygcheck output. Ah, that is an interesting one: $ rebase -si rebase: failed to open rebase database /etc/rebase.db.i386: No such file or directory ...this here means that rebase never created the database, which in turn could point to rebase crashing or not having sufficient privileges on /etc. Something like that. What happens if you stop all Cygwin processes, including any service you installed, then start dash, make sure you're in /bin, and then call `./rebaseall -p'. Any helpful output? How about this; sure looks like something is wrong: ./rebaseall -p gzip: stdin: unexpected end of file Yes, something is wrong. Looks like you removed the /etc/setup directory or the contents of that dir. The content is created and maintained by the setup installer and rebaseall needs the information. Don't play games with the files under /etc unless you want to break your installation. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpyW85g3dZhr.pgp Description: PGP signature
Re: emacs won't run
On Wed, Dec 04, 2013 at 11:56:11AM +0100, marco atzeri wrote: Il 12/4/2013 10:20 AM, Andrea Venturoli ha scritto: Hello. Since a bit, emacs won't start under X: no error, no message, nothing. It just starts and exits after a while without doing anything. I can run emacs -nw fine. How can I diagnose this? Is there any log I can look into? Any utility? bye Thanks av. use strace. Wouldn't cygcheck /usr/bin/emacs be a better first step? It sounds like it could be a missing DLL. 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
cygwin 1.7.26-1 causes Too many open files error in squid
I'm running squid on cygwin64 under Windows 7. All packages on my system are at the latest versions. After upgrading the cygwin package to 1.7.26-1, I started getting errors in squid which causes it to abort. Rolling the cygwin package back to 1.7.25-1 resolves the issue. Here are the errors in squid's cache.log: 2013/12/04 11:23:44| comm_open: socket failure: (24) Too many open files 2013/12/04 11:23:44| WARNING: This machine has a serious shortage of filedescriptors. 2013/12/04 11:23:44| Closing HTTP port [::]:3128 2013/12/04 11:23:44| storeDirWriteCleanLogs: Starting... 2013/12/04 11:23:44| Finished. Wrote 0 entries. 2013/12/04 11:23:44| Took 0.00 seconds ( 0.00 entries/sec). FATAL: Received Segment Violation...dying. 2013/12/04 11:23:44| storeDirWriteCleanLogs: Starting... 2013/12/04 11:23:44| Finished. Wrote 0 entries. 2013/12/04 11:23:44| Took 0.00 seconds ( 0.00 entries/sec). - Scuz -- 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 1.7.26-1 causes Too many open files error in squid
On 12/4/2013 2:28 PM, Scuzuliak wrote: I'm running squid on cygwin64 under Windows 7. All packages on my system are at the latest versions. After upgrading the cygwin package to 1.7.26-1, I started getting errors in squid which causes it to abort. Rolling the cygwin package back to 1.7.25-1 resolves the issue. I was able to resume use of gcc and gfortran after similar rollback. The update produced immediate segfault on the most trivial test compilation cases. -- Tim Prince -- 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: Problem with command substitution in mksh shell after upgrading to Cygwin 1.7.26
Hi,
The fix did help. Thank you.
Thanks,
George
-Original Message-
Of Corinna Vinschen
Sent: Wednesday, December 04, 2013 6:17 AM
Subject: Re: Problem with command substitution in mksh shell after upgrading
to
Cygwin 1.7.26
On Dec 4 10:13, Corinna Vinschen wrote:
On Dec 4 03:22, PRIKHODKO, GEORGE wrote:
Hi,
After upgrading to Cygwin to 1.7.26 the commands:
print $(getIP)
print $(ipconfig | grep IPv4 Address | sort | head -1 | cut -d : -f 2
\
| sed -e s/ *\\([0-9.]*\\).*/\\1/)
in the following script
#!/usr/bin/ksh
cv=$(uname -r)
cv=${cv%\(*}
cygcheck -s -v -r cygcheck_$cv.out
exec test_$cv.log 21
set -xv
getIP() {
ipconfig | grep IPv4 Address | sort | head -1 | cut -d : -f 2 \
| sed -e s/ *\\([0-9.]*\\).*/\\1/
}
#
# the following four commands should print IP address 4 times
#
getIP
print $(getIP)
ipconfig | grep IPv4 Address | sort | head -1 | cut -d : -f 2 \
| sed -e s/ *\\([0-9.]*\\).*/\\1/
print $(ipconfig | grep IPv4 Address | sort | head -1 | cut -d : -f 2
\
| sed -e s/ *\\([0-9.]*\\).*/\\1/)
exit
started to produce incorrect results.
test_1.7.26.log shows instead of IP address a whole output of ipconfig is
printed for these lines.
/usr/bin/ksh, used in the script, is a symbolic link to /usr/bin/mksh
Please, let me know if you need more info to research the problem.
No, thank you. I could track down the culprit of the problem.
I don't have a fix yet, but it will be fixed in 1.7.27, which
will be due really soon.
The fix was already in CVS. Please try the latest snapshot from
http://cygwin.com/snapshots/, it should already contain the patch.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
Re: cygwin 1.7.26-1 causes Too many open files error in squid
On Dec 4 14:46, Tim Prince wrote: On 12/4/2013 2:28 PM, Scuzuliak wrote: I'm running squid on cygwin64 under Windows 7. All packages on my system are at the latest versions. After upgrading the cygwin package to 1.7.26-1, I started getting errors in squid which causes it to abort. Rolling the cygwin package back to 1.7.25-1 resolves the issue. I was able to resume use of gcc and gfortran after similar rollback. The update produced immediate segfault on the most trivial test compilation cases. http://cygwin.com/ml/cygwin/2013-12/msg7.html http://cygwin.com/snapshots/ Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpx8ZJnXuADN.pgp Description: PGP signature
Re: C:\cygwin\bin\cyggcc_s-1.dll: Loaded to different address
On 12/04/2013 05:53 PM, Corinna Vinschen wrote: On Dec 4 17:41, bartels wrote: On 12/04/2013 03:23 PM, Corinna Vinschen wrote: On Dec 4 14:53, bartels wrote: On 12/04/2013 02:11 PM, marco atzeri wrote: Il 12/4/2013 1:35 PM, bartels ha scritto: On 12/04/2013 01:23 PM, marco atzeri wrote: I am looking for the cause of the problem, so that I know how to prevent it. Or is the only answer to simply run rebaseall after installation? usually yes If that is the case, then why is it not part of the installation? currently, it is part of the installation /etc/postinstall/autorebase.bat.done $ cygcheck -f /etc/postinstall/autorebase.bat _autorebase-000444-1 Your attached cygcheck output claims something else. The rebase version should be updated to 4.4.1 as well. Don't think there is a mismatch: that output was Marco's, not mine. Unless I misunderstand . . . http://cygwin.com/ml/cygwin/2013-12/msg00085.html was your mail, so it's kind of hard to imagine that the attached cygcheck output was Marco's. Check the version numbers. It's _autorebase-000425-1 and rebase-4.4.0-1 in the cygcheck output. Okay, I see. It takes a cygwin expert to spot that one. No way I could tell that those two should match somehow. Ah, that is an interesting one: $ rebase -si rebase: failed to open rebase database /etc/rebase.db.i386: No such file or directory ...this here means that rebase never created the database, which in turn could point to rebase crashing or not having sufficient privileges on /etc. Something like that. What happens if you stop all Cygwin processes, including any service you installed, then start dash, make sure you're in /bin, and then call `./rebaseall -p'. Any helpful output? How about this; sure looks like something is wrong: ./rebaseall -p gzip: stdin: unexpected end of file Yes, something is wrong. Looks like you removed the /etc/setup directory or the contents of that dir. The content is created and maintained by the setup installer and rebaseall needs the information. Don't play games with the files under /etc unless you want to break your installation. It was never the idea to break the installation :) But, evidently, I did botch my bundle, so to speak. Rebase is fine now; all I get is this harmless (?) message: /usr/lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14_2.dll: skipped because nonexistent. Nonexistent is not the whole truth: it's just a dangling symlink. Sibling cygperl5_14.dll is fine Is that a bug or my doing? Thanks for your (plural, including Marco) most excellent help. -- - Bartels -- 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: Please try newest snapshot (was Re: emacs-x11: new clipboard size limitation?)
Around 2013-12-04 16:59 Jon TURNEY was heard to say: On 04/12/2013 08:09, Markus Hoenicka wrote: Am 2013-12-03 22:10, schrieb Christopher Faylor: I added an ugly hack to work around this symptom in the latest cygwin. It shouldn't have any big impact on anything but this particular scenario but I would appreciate it if people downloaded today's snapshot and verified that things are still working ok. I plan on addressing the actual problem for Cygwin 1.7.28. the nightly snapshot does not seem to do me any good with regard to the clipboard problem. I performed the following test, and I hope this is what you had in mind: There is also a bug in xwinclip which needs fixing for this test to work reliably, but it was difficult to see what that was without this fix in the cygwin DLL. I see. Let me know whenever it makes sense to do any further testing. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- 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: emacs won't run
Il 12/4/2013 8:21 PM, Christopher Faylor ha scritto: On Wed, Dec 04, 2013 at 11:56:11AM +0100, marco atzeri wrote: Il 12/4/2013 10:20 AM, Andrea Venturoli ha scritto: Hello. Since a bit, emacs won't start under X: no error, no message, nothing. It just starts and exits after a while without doing anything. I can run emacs -nw fine. How can I diagnose this? Is there any log I can look into? Any utility? bye Thanks av. use strace. Wouldn't cygcheck /usr/bin/emacs be a better first step? It sounds like it could be a missing DLL. likely it is a missing/wrong DLL, but he mentioned that emacs -nw is working, so should be not a static one and cygcheck could miss the issue. cgf Marco -- 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
absolute native symlinks vs file explorer on windows 8.1
I'm experiencing the following symptom with the latest 64bit cygwin on windows 8.1: absolute native symlinks created with cygwin differ slightly from those created with mklink; cygwin's symlinks start with a \\?\ . Because of this, file explorer (nee windows explorer) refuses to handle them properly, specifically, nothing happens when I double click on such a symlink. See exact repro below. Cygwin exhibits the same behavior on windows 7, but windows 7's explorer handles such symlinks fine. Questions: - Why does the target of the native cygwin symlink start with \\?\ ? - Is there a way to make cygwin not add that prefix to native symlinks? - Alternatively, is there a way to make windows 8's file explorer behave like windows 7's explorer and tolerate such native symlinks? (I'm am aware of the alternative involving shortcuts instead of native symlinks, however, I'm interested in finding a fix or workaround for the native symlink case.) cheers, Andras repro steps (~/v.txt exists and is a plain text file): $ export CYGWIN=winsymlinks:nativestrict $ ln -s ~/v.txt v1.txt $ cmd /c mklink v2.txt $(cygpath -w ~/v.txt) symbolic link created for v2.txt === C:\Users\nagya\home\v.txt $ ls -l lrwxrwxrwx 1 nagya None 17 Nov 30 21:42 v1.txt - /home/nagya/v.txt lrwxrwxrwx 1 nagya None 17 Nov 30 21:42 v2.txt - /home/nagya/v.txt $ cmd /c dir 11/30/13 09:42 PMSYMLINK v1.txt [\\?\C:\Users\nagya\home\v.txt] 11/30/13 09:42 PMSYMLINK v2.txt [C:\Users\nagya\home\v.txt] $ cygstart v1.txt Unable to start 'v1.txt': There is no application associated with the given file name extension. $ cygstart v2.txt # succeeds, opens v.txt in notepad (not v2.txt, i.e. explorer dereferenced the link and started notepad with the target) # (By contrast on win7, both cygstart commands succeed and open v1.txt and v2.txt respectively, i.e. there's no dereferencing.) -- 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
