w32api-headers-3.0.0.-1 in question
Hello, I use cygwin 32 bits, last snapshot. Since the last update of - mingw64-i686-headers-3.0.0-1 - mingw64-i686-runtime-3.0.0-1 - w32api-headers-3.0.0-1 - w32api-runtime-3.0.0-1 (see http://cygwin.com/ml/cygwin-announce/2013-09/msg00018.html) i'm no longer able to compile the last cygwin snapshot (20130925). With the Previous issues of these packages (3.0b_svn5935), all is ok. The errors i get are as follows (below). Regards, Denis Excoffier. In file included from /tmp/lcl/tmp/cygwin/cygwin-snapshot-20130925-1/winsup/cygwin/cygtls.h:279:0, from ./globals.h:5, from /tmp/lcl/tmp/cygwin/cygwin-snapshot-20130925-1/winsup/cygwin/winsup.h:302, from /tmp/lcl/tmp/cygwin/cygwin-snapshot-20130925-1/winsup/cygwin/lib/_cygwin_crt0_common.cc:12: /tmp/lcl/tmp/cygwin/cygwin-snapshot-20130925-1/winsup/cygwin/ntdll.h:72:0: error: "TRANSACTION_ALL_ACCESS" redefined [-Werror] In file included from /usr/include/w32api/minwindef.h:146:0, from /usr/include/w32api/windef.h:8, from /usr/include/w32api/windows.h:69, from /tmp/lcl/tmp/cygwin/cygwin-snapshot-20130925-1/winsup/cygwin/winlean.h:52, from /tmp/lcl/tmp/cygwin/cygwin-snapshot-20130925-1/winsup/cygwin/winsup.h:76, from /tmp/lcl/tmp/cygwin/cygwin-snapshot-20130925-1/winsup/cygwin/lib/_cygwin_crt0_common.cc:12: /usr/include/w32api/winnt.h:8184:0: note: this is the location of the previous definition In file included from /tmp/lcl/tmp/cygwin/cygwin-snapshot-20130925-1/winsup/cygwin/cygtls.h:279:0, from ./globals.h:5, from /tmp/lcl/tmp/cygwin/cygwin-snapshot-20130925-1/winsup/cygwin/winsup.h:302, from /tmp/lcl/tmp/cygwin/cygwin-snapshot-20130925-1/winsup/cygwin/lib/_cygwin_crt0_common.cc:12: /tmp/lcl/tmp/cygwin/cygwin-snapshot-20130925-1/winsup/cygwin/ntdll.h:1117:14: error: multiple definition of â In file included from /tmp/lcl/tmp/cygwin/cygwin-snapshot-20130925-1/winsup/cygwin/winbase.h:9:0, from /usr/include/w32api/windows.h:70, from /tmp/lcl/tmp/cygwin/cygwin-snapshot-20130925-1/winsup/cygwin/winlean.h:52, from /tmp/lcl/tmp/cygwin/cygwin-snapshot-20130925-1/winsup/cygwin/winsup.h:76, from /tmp/lcl/tmp/cygwin/cygwin-snapshot-20130925-1/winsup/cygwin/lib/_cygwin_crt0_common.cc:12: /usr/include/w32api/winbase.h:1160:16: error: previous definition here In file included from /tmp/lcl/tmp/cygwin/cygwin-snapshot-20130925-1/winsup/cygwin/cygtls.h:279:0, from ./globals.h:5, from /tmp/lcl/tmp/cygwin/cygwin-snapshot-20130925-1/winsup/cygwin/winsup.h:302, from /tmp/lcl/tmp/cygwin/cygwin-snapshot-20130925-1/winsup/cygwin/lib/_cygwin_crt0_common.cc:12: /tmp/lcl/tmp/cygwin/cygwin-snapshot-20130925-1/winsup/cygwin/ntdll.h:1122:27: error: invalid type in declaration before â token /tmp/lcl/tmp/cygwin/cygwin-snapshot-20130925-1/winsup/cygwin/ntdll.h:1122:27: error: conflicting declaration â In file included from /tmp/lcl/tmp/cygwin/cygwin-snapshot-20130925-1/winsup/cygwin/winbase.h:9:0, from /usr/include/w32api/windows.h:70, from /tmp/lcl/tmp/cygwin/cygwin-snapshot-20130925-1/winsup/cygwin/winlean.h:52, from /tmp/lcl/tmp/cygwin/cygwin-snapshot-20130925-1/winsup/cygwin/winsup.h:76, from /tmp/lcl/tmp/cygwin/cygwin-snapshot-20130925-1/winsup/cygwin/lib/_cygwin_crt0_common.cc:12: /usr/include/w32api/winbase.h:1164:5: error: â has a previous declaration as â cc1plus: all warnings being treated as errors make[3]: *** [_cygwin_crt0_common.o] Error 1 make[2]: *** [cygwin] Error 1 make[1]: *** [all-target-winsup] Error 2 make: *** [all] Error 2 -- 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-src-20131107.tar.xz
Hello, The x86/cygwin-src-20131107.tar.xz seems to be missing in the snapshot http page and folder. Without this file, i cannot see how to get an uptodate winsup/../newlib in order to compile the 20131107 snapshot. Regards, Denis Excoffier. -- 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: How about a 64-bit installer that doesn't require UAC?
On 2013-11-08 15:01, Shaddy Baddah wrote: > In my view, this option should only be used by users who understand well > enough general Windows file permissions, user privileges, etc... > the general security model, and how Cygwin functions accordingly. Well, i would say the reverse (i.e. elevation is for knowledgeable people), but never mind. More importantly, the new —no-admin/-B option is especially beneficial for users that are not allowed to elevate or that do not know any Administrator password. Denis Excoffier. -- 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: Intermittent failures retrieving process exit codes
On 2013-11-14 05:01, Tom Honermann wrote: > On 12/21/2012 01:30 AM, Tom Honermann wrote: >> >> The workaround I implemented within Cygwin was simple and sloppy. I >> added a call to Sleep(1000) immediately before the call to ExitThread() >> in wait_sig() in winsup/cygwin/sigproc.cc. Since this thread (probably) >> doesn't exit until the process is exiting anyway, the call to Sleep() >> does not adversely affect shutdown. The thread just gets terminated >> while in the call to Sleep() instead of exiting before the process is >> terminated or getting terminated while still in the call to >> ExitThread(). A better solution might be to avoid the thread exiting at >> all (so long as it can't get terminated while holding critical >> resources), or to have the process exiting thread wait on it. Neither >> of these is ideal. Orderly shutdown of multi-threaded processes is >> really hard to do correctly on Windows. I experience on Windows 7 (not on XP) some problems that may be related. I would like to test your workaround, but sigproc.cc has much changed since then, there is now an exit_thead function with the comment "Exit the current thread very carefully.". I tried to insert Sleep(1000) at the end of exit_thread, immediately before "ExitThread (0)", but this yielded no change at all. Could someone be kind enough to update the workaround for modern sigproc.cc? Very briefly, my problem is that when i "tar xf —use-compress-program=xz", i get: tar: Unexpected EOF in archive tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now and the last file of the archive is truncated at some 512bytes block. This occurs on Windows 7 (not on XP); with xz-5.1.3alpha (not with xz-5.1.2alpha or xz-5.0.5); never on most tar.xz files; almost always on some (rare) tar.xz files (one notable example is bc-1.06.95.tar.bz2 bunzip2’ed and then xz’ed); depends on the .tar file itself, not on the option (like -9e, -0) used to create the .tar.xz; never with "tar tf"; and with all tar’s i have tested. The return code of all the involved xz -d commands is always zero though. Perhaps after all, this is unrelated? Thank you. Regards, Denis Excoffier. -- 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: Intermittent failures retrieving process exit codes
On 2013-11-15 20:21, Christopher Faylor wrote: > On Fri, Nov 15, 2013 at 07:53:26PM +0100, Denis Excoffier wrote: >> On 2013-11-14 05:01, Tom Honermann wrote: >>> On 12/21/2012 01:30 AM, Tom Honermann wrote: >>>> >>>> The workaround I implemented within Cygwin was simple and sloppy. I >>>> added a call to Sleep(1000) immediately before the call to ExitThread() >>>> in wait_sig() in winsup/cygwin/sigproc.cc. Since this thread (probably) >>>> doesn't exit until the process is exiting anyway, the call to Sleep() >>>> does not adversely affect shutdown. The thread just gets terminated >>>> while in the call to Sleep() instead of exiting before the process is >>>> terminated or getting terminated while still in the call to >>>> ExitThread(). A better solution might be to avoid the thread exiting at >>>> all (so long as it can't get terminated while holding critical >>>> resources), or to have the process exiting thread wait on it. Neither >>>> of these is ideal. Orderly shutdown of multi-threaded processes is >>>> really hard to do correctly on Windows. >> >> I experience on Windows 7 (not on XP) some problems that may be related. >> I would like to test your workaround, but sigproc.cc has much changed since >> then, there is now an exit_thead function with the comment "Exit the current >> thread very carefully.". I tried to insert Sleep(1000) at the end of >> exit_thread, immediately before "ExitThread (0)", but this yielded no >> change at all. >> >> Could someone be kind enough to update the workaround for modern sigproc.cc? > > You apparently are misunderstanding the whole point of the changes to > sigproc.cc. They were to work around this very problem. Oh, i didn’t remember that. Then this must be the antivirus or something else i have to cope with. Regards, Denis Excoffier. -- 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 test latest snapshots 2013-11-20
On 2013-11-23 12:36, Corinna Vinschen wrote: > Hi folks, > > we're planning to release Cygwin 1.7.26 next week. It would be quite > helpful if those of you comfortable to install snapshots would perform > some last-minute testing. I have no new (see below) problem to report with this latest snapshot (20131123) itself, but it’s a pity that we cannot compile it under (itself and) the latest cygwin packages (see http://cygwin.com/ml/cygwin/2013-10/msg00382.html, seems related to the new /usr/include/spawn.h). On the other hand, using: - w32api-headers 3.0b_svn5935-1 instead of 3.0.0-1 - w32api-runtime 3.0b_svn5935-1 instead of 3.0.0-1 - mingw64-i686-headers 3.0b_svn5935-1 instead of 3.0.0-1 - mingw64-i686-runtime 3.0b_svn5935-2 instead of 3.0.0-1 (i’m under i686) all is fine (in particular using the new gcc-4.8.2). Denis Excoffier. (below is here:) We still have the python problem reported in May (see http://cygwin.com/ml/cygwin/2013-05/msg00322.html) -- 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 test latest snapshots 2013-11-20
2013-11-23 13:25 -05:00, Christopher Faylor wrote: > On Sat, Nov 23, 2013 at 05:11:23PM +0100, Denis Excoffier wrote: >> On 2013-11-23 12:36, Corinna Vinschen wrote: >>> we're planning to release Cygwin 1.7.26 next week. It would be quite >>> helpful if those of you comfortable to install snapshots would perform >>> some last-minute testing. >> >> I have no new (see below) problem to report with this latest snapshot >> (20131123) itself, > > There is no 20131123 snapshot. My mistake, sorry. Still a little bit more than 0.5 hour to create one however... > >> but it’s a pity that we cannot compile it under (itself and) the >> latest cygwin packages (see >> http://cygwin.com/ml/cygwin/2013-10/msg00382.html, seems related to the >> new /usr/include/spawn.h). >> >> On the other hand, using: - w32api-headers 3.0b_svn5935-1 instead of >> 3.0.0-1 - w32api-runtime 3.0b_svn5935-1 instead of 3.0.0-1 - >> mingw64-i686-headers 3.0b_svn5935-1 instead of 3.0.0-1 - >> mingw64-i686-runtime 3.0b_svn5935-2 instead of 3.0.0-1 (i’m under >> i686) >> >> all is fine (in particular using the new gcc-4.8.2). > > As the above quoted issue states, if you are having problems building > then please provide patches. I was not able to do this until now. > > However, given that the problem regards a header file that that Corinna > specifically mentioned as going away, it seems like that particular > problem can no longer occur. You must be talking about /usr/include/exceptions.h. I did remove it from my system on the very first snapshot that removed it (see a similar issue about /usr/include/process.h under http://cygwin.com/ml/cygwin/2012-02/msg00130.html). Without /usr/include/exceptions.h and with all 3.0.0-1 packages (see above) included, i obtain the symptoms shown in http://cygwin.com/ml/cygwin/2013-11/msg00364.html and discussed in http://cygwin.com/ml/cygwin/2013-11/msg00368.html . Regards, Denis Excoffier. -- 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 test latest snapshots 2013-11-20
On 2013-11-24 14:21 +01:00, Corinna Vinschen wrote: > On Nov 24 14:14, Corinna Vinschen wrote: >> On Nov 24 00:27, Denis Excoffier wrote: >>> You must be talking about /usr/include/exceptions.h. I did remove it from >>> my system on the very first snapshot that removed it (see a similar >>> issue about /usr/include/process.h under >>> http://cygwin.com/ml/cygwin/2012-02/msg00130.html). Without >>> /usr/include/exceptions.h and with all 3.0.0-1 packages (see above) >>> included, i obtain the symptoms shown in >>> http://cygwin.com/ml/cygwin/2013-11/msg00364.html and discussed in >>> http://cygwin.com/ml/cygwin/2013-11/msg00368.html . >> >> Fixed in CVS. The latest mingw-w64 winnls.h header introduces a new >> symbol _NORMALIZE_ which controls the usage of DECLSPEC_IMPORT for >> the functions declared in that header, rather than using _KERNEL32_ >> as former versions of winnls.h did. This breaks the autoload mechanism, >> so we have to change our sources and define _NORMALIZE_ ourselves to >> stay compatible with Mingw-w64 headers. Grr. >> >> I'm just creating new snapshots 2013-11-24 with Eric's and my patch. >> Should be both up in about half an hour. > > Only the 32 bit snapshot is up. I'm unable to generate the 64 bit > snapshot for some reason and I have no more time to investigate > today, sorry. > Corinna, I installed the last w32api and mingw64-i686 packages and (installed and) compiled the 20131124 snapshot with no problem, under both XP and Seven. In addition, i didn’t discover any issue with the snapshot itself. Thankyou for all. Denis Excoffier. Note. For the record, previous mingw64-i686-headers was needed for Tcl 8.6.1, not for cygwin. -- 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
Antivirus strikes back (probably) (Was: Intermittent failures retrieving process exit codes)
On 2013-11-25 à 21:58 +02:00, Lasse Collin wrote: > On 2013-11-15 Denis Excoffier wrote: >> Very briefly, my problem is that when i "tar xf >> —use-compress-program=xz", i get: >> tar: Unexpected EOF in archive >> tar: Unexpected EOF in archive >> tar: Error is not recoverable: exiting now >> and the last file of the archive is truncated at some 512bytes block. >> This occurs on Windows 7 (not on XP); with xz-5.1.3alpha (not with >> xz-5.1.2alpha or xz-5.0.5); never on most tar.xz files; almost always >> on some (rare) tar.xz files (one notable example is >> bc-1.06.95.tar.bz2 bunzip2’ed and then xz’ed); depends on the .tar >> file itself, not on the option (like -9e, -0) used to create >> the .tar.xz; never with "tar tf"; and with all tar’s i have tested. >> The return code of all the involved xz -d commands is always zero >> though. Perhaps after all, this is unrelated? > > xz 5.1.3alpha has some new file I/O code that uses non-blocking file > descriptors, the self-pipe trick, and poll(). It's there to fix a race > condition in signal handling. Since you say it works with 5.1.2alpha, I > wonder could there be a bug with the new I/O code in xz or if the code > in xz triggers a bug in Cygwin or Windows. > > If you haven't already tried, please compile both 5.1.2alpha and > 5.1.3alpha from source while keeping everything else unchanged, and see > if the bug really only occurs with 5.1.3alpha. Already done. I did some strace-ing, and since i’m not so fluent with the result, i’ll send it there in a while (when i’m back on cygwin) if someone is interested. But the bug (contrary to what i said before) also _sometimes_ occurs with 5.1.2alpha or 5.0.5 and this makes me think now that: a) my antivirus-anti-intrusion-whatever-software (that i can’t remove of course) creates some kind of "background noise" where a certain percentage of such ‘tar xf —use-compress-program’ commands will always fail b) nevertheless, xz-5.1.3alpha (with its new file I/O code etc.) triggers some untypical configuration inside the antivirus that increases drastically the percentage, making the failure almost certain for some files. It is not extraordinary that i cannot observe the failure on XP since i do not have this particular antivirus on XP. You might however want some more detail. Test plan is: perform 'tar xf file.xz --use-compress-program=xz -bx', where x varies from 1 to 200. There are two kinds of results: 1) usual situation is where you observe max 1 or 2 failures (on a maximum of 200). If you launch the same plan, you still report max 1 or 2 failures, usually not with the same numbers. Very often you have no failure at all. Very often the -b20 (the default) does not fail. -> this situation occurs with 5.1.2alpha or 5.0.5 with all input files, or with 5.1.3alpha with most input files. 2) pathological situation is where you observe, say, 30 failures (on a maximum of 200). If you launch the same plan, you report nearly the same failures, ie mostly the same ones, with some minor variability analogous to the variability observed in the usual situation above -> this situation occurs with 5.1.3alpha only, with some selected input files, eg bc-1.06.95.tar.xz (see above how to create bc-1.06.95.tar.xz) When it fails (usually or pathologically), the last file of the archive gets truncated (see above), and _this_ is strange from an antivirus behaviour. After all, perhaps some flush() or similar is missing inside 5.1.3alpha. Denis Excoffier. -- 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
snapshot 20131201 (dated 17:53:27)
Hello, I’m under Windows XP 32bits. I installed the last snapshot (20131201, 17:53:27). And now: % /usr/bin/make -f /dev/null make: *** Too many open files. Stop. % The first snapshot of today (20131201, 03:03:01) was ok: % /usr/bin/make -f /dev/null make: *** No targets. Stop. % Regards, Denis Excoffier. -- 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: snapshot 20131201 (dated 17:53:27)
On 2013-12-01 14:42 -05:00, Christopher Faylor wrote: > On Sun, Dec 01, 2013 at 07:55:43PM +0100, Denis Excoffier wrote: >> I'm under Windows XP 32bits. I installed the last snapshot (20131201, >> 17:53:27). And now: >> >> % /usr/bin/make -f /dev/null make: *** Too many open files. Stop. % > > That should be fixed in the latest snapshot. % uname -v 20131201 19:20:18 % /usr/bin/make -f /dev/null make: *** No targets. Stop. % Indeed. Thank you. Denis Excoffier. -- 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
snapshot dated 20131206
Hello, The last snapshot (dated 20131206) seems to work perfectly. Recompilation with all last to-date packages also, under XP and Seven (32bits). A detail about the packaging: snapshot dated 20131205 is called "20131205 01:10:29 UTC" within the snapshot page (for the x86 flavor). Nevertheless, it includes changes dated 2013-12-05 19:43:34 as reported in http://cygwin.com/ml/cygwin-cvs/2013-q4. Also, i’m pretty sure that it was not present yesterday (local). It seems in fact that in "20131205 01:10:29 UTC", the date (20131205) is local (eg UTC -0500) and the time (01:10:29) is UTC. The snapshot should have been named 20131206 i suppose. Regards, Denis Excoffier. -- 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
snapshots dated 20140210 fail
Hello, I use XP SP3 with 32 bits and also Seven 32 bits. Today i could exercise 4 new snapshots. The first two had the same problem (tested on XP): it seems that every program that has to perform something in connection with user/id/passwd etc. produces a stackdump (id, tar etc.). The last two (the last one is dated 18:34:44 UTC) had the same problem (first tested on XP, second on Seven): windows produces a message showing ‘bash.exe’ complaining that cygwin1.dll is not a valid windows image. After that, i’m back into 1.7.28-2 or snapshot-dated-20140209. But which one is the latest? Compare the following: With snapshot-dated-20140909, cat /proc/version | tr ‘\100’ ‘Z’ produces: CYGWIN_NT-6.1-WOW64 version 1.7.29s(0.271/5/3) (cgfZ) (gcc version 4.7.3 20130411 (Fedora Cygwin 4.7.3-1) (GCC) ) 20140209 18:32:26 while cygwin-1.7.28-2 produces: CYGWIN_NT-5.1 version 1.7.28(0.271/5/3) (corinnaZcalimero.vinschen.de) (gcc version 4.8.2 20131016 (Fedora Cygwin 4.8.2-2) (GCC) ) 2014-02-09 21:06 Ok, the first one is from Seven, the second one is from XP. But, since this is local time, it’s perhaps ok that the time of 1.7.29s is _before_ 1.7.28-2. But what for the format of this `uname -v` part? Dashes or not? Seconds or not? By the way, after comparison of cygwin-1.7.28-2-src.tar.xz and cygwin-src-20140209.tar.xz, none of them contains/supersedes the other one. I can live with this. However the snapshots don’t work for me. Regards, Denis Excoffier. -- 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: snapshots dated 20140210 fail
On 2014-02-10 23:05, Denis Excoffier wrote: > Hello, > > I use XP SP3 with 32 bits and also Seven 32 bits. Today i could exercise 4 > new snapshots. > I can see another one, dated 22:17:21 UTC. Same problem as for the 3rd and 4th: windows complaint that this is not a windows image. Denis Excoffier -- 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: snapshots dated 20140210 fail
On 2014-02-11 10:20, Corinna Vinschen wrote: > On Feb 10 16:09, Warren Young wrote: >> On 2/10/2014 15:53, Denis Excoffier wrote: >>> >>> I can see another one, dated 22:17:21 UTC. Same problem as for the >>> 3rd and 4th: windows complaint that this is not a windows image. >> >> Confirmed. > > Can you please both test the snapshot DLLs from today? Both versions, > 32 and 64 bit, work fine for me on Windows 8.1. Tested the snapshot (of today) dated 18:45:46 UTC (18:42:13 inside), and it seems to work perfectly. I’ve also successfully built it from sources. Thank you. Denis Excoffier. -- 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: snapshots dated 20140210 fail
On 2014-02-11 21:39, Denis Excoffier wrote: > On 2014-02-11 10:20, Corinna Vinschen wrote: >> On Feb 10 16:09, Warren Young wrote: >>> On 2/10/2014 15:53, Denis Excoffier wrote: >>>> >>>> I can see another one, dated 22:17:21 UTC. Same problem as for the >>>> 3rd and 4th: windows complaint that this is not a windows image. >>> >>> Confirmed. >> >> Can you please both test the snapshot DLLs from today? Both versions, >> 32 and 64 bit, work fine for me on Windows 8.1. > Tested the snapshot (of today) dated 18:45:46 UTC (18:42:13 inside), and it > seems to work perfectly. > I’ve also successfully built it from sources. > Oops, i believe i was too enthusiastic. In fact i tested on XP SP3 only. But on Seven, it does not seem to work (/usr/bin/id still dumps core). Denis Excoffier. -- 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
snapshot dated 20140310 fails under XP
Hello, Under XP/x86, the last snapshot (20140310) cannot be launched and Windowos produces (translated from french): "entry point GetConsoleScreenBufferInfoEx is not found in KERNEL32.DLL" The last snapshot dated 20140309 also produces this message, but a preceeding one also dated 20140309 (which is not visible any more) was perfectly working. Under W7/x86 all of them work correctly. By the way, one question: does anybody know when the support for XP SP3 is expected to be discontinued? Regards, Denis Excoffier. -- 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: binutils-2.24.51-1 (x86/x86_64)
On 2014-03-15 20:33, Christopher Faylor wrote: > I've made a new version of binutils available for installation. This is > a refresh against the official git repository. The binutils package > contains the GNU assembler, linker and binary utilities. It is > available in the "Devel" category under Cygwin's setup. This new version 2.24.51 needs (at least on x86) the addition of /usr/lib/libiberty.a (that was present in 2.23.51) in order to compile the 20140317 snapshot successfully (see the target dumper.exe). Regards, Denis Excoffier. -- 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: mingw64-*-binutils-2.24.0.1.acd6540-1 (x86/x86_64)
On 2014-03-30 16:58, JonY wrote: > > Version 2.24.0.1.acd6540-1 of mingw64-*-binutils have been uploaded. > > This is a bug fix release from git. > This must be more than a simple bug fix release. I’m talking about the mingw64-x86_64-binutils-2.24.0.1.acd6540-1.tar.xz, which does not contain usr/bin/x86_64-w64-mingw32-ld.exe although mingw64-x86_64-binutils-2.24.0.0.5a026fc-1.tar.xz did. This prevents me from compiling the last cygwin snapshot (target cyglsa64.dll fails because of ‘ld’ missing). More than that, the new package contains usr/share/info/binutils.info (which the previous one didn’t), but this file is already provided by the binutils-2.24.51-2 package (with the .gz suffix, i must however recognize). Please someone to confirm that this new mingw64-x86_64-binutils package is indeed ok. Regards, Denis Excoffier. -- 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
gcc-4.9.0-RC-20140411
Hello, Yesterday i tried to bootstrap the new gcc-4.9.0-RC-20140411 (with snapshot 20140412 installed), but didn’t manage to come to a satisfactory end. Not the snapshot fault i suppose. For the interested people, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 . Regards, Denis Excoffier. -- 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: mingw64-*-binutils-2.24.0.3.85cf705-1 (x86/x86_64)
On 2014-04-16 10:20, Angelo Graziosi wrote: > JonY wrote: >> This removes the previously included default-manifest.o file support. It > > This release fixes the issue I flagged here > > http://cygwin.com/ml/cygwin/2014-04/msg00016.html > > > at least from Mingw64 side (Cygwin Windows "native" applications still suffer > the issue). > Me too, see http://cygwin.com/ml/cygwin/2014-04/msg3.html Denis Excoffier. -- 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
thank you for vsnprintf et al
Hello, The recent snapshots (since 20140505) contain (in /usr/include/stdio.h) the declarations of the vsnprintf(), snprintf() etc. functions, including (this is new) for under strict C++11 (i.e. 'gcc -std=c++11’). I think this is worth noting. And thank you. Denis Excoffier. -- 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
getent group fails
Hello, I'm under x86, with no /etc/nsswitch.conf, and my /etc/passwd and group files with 1 line each (me and 'Domain Users'). The command 'getent group' seems to loop forever on the 'Users' group: % /usr/bin/getent group Domain Users:S-1-5-21-878717028-1334384809-310601177-513:10513: +Users:S-1-5-32-545:545: ... +Users:S-1-5-32-545:545: ^C % 'getent passwd' seems ok (9 lines): my line and 8 lines beginning with '+’. I tried several snapshots (including 20140507), and this bahaviour was already present in snapshot 20140410 (the first one where the "Corinna's prize-winning passwd/group rewrite" was reintroduced). It was not present in snapshot 20140305. Regards, Denis Excoffier. -- 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: getent group fails
On 2014-05-09 11:13, Corinna Vinschen wrote: > On May 7 19:39, Denis Excoffier wrote: > Thanks for the report. I made a dumb Copy/paste error. This should > be fixed in the today's snapshot from http://cygwin.com/snapshots/ Indeed, it is working now. Also, i have noticed that 'getent group' produces this line: +Utilisateurs authentifiés:S-1-5-11:11: (with \303\251 meaning é, like under UTF-8) while 'getent passwd' produces (among other lines): +SERVICE RÉSEAU:*:20:20:,S-1-5-20:/:/sbin/nologin (with \311 meaning É, like under ISO-Latin) This is with LC_CTYPE=fr_FR, no /etc/nsswitch.conf, /etc/passwd and /etc/group with only one line each, domain member with currently no network connected, under Cygwin 32bits 'Just Me', installed on top of XP SP3 32bits [french only], with snapshot '20140508 19:51:25’, and all packages up-to-date. If i setenv LC_CTYPE C, or unsetenv LC_CTYPE, i also get UTF-8 for 'getent passwd' (ie for both). What bothers me is that under LC_CTYPE=fr_FR (or fr_FR@euro), the getent output is not consistent. Regards, Denis Excoffier. -- 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
typo correction (patch)
Hello, I propose the following patch, in order to make getgrouplist() to produce a better result, in particular when the number of groups of a user is more than the first value used by coreutils/id (which is only 10). diff -uNr cygwin-snapshot-20140523-1.original/winsup/cygwin/grp.cc cygwin-snapshot-20140523-1.patched/winsup/cygwin/grp.cc --- cygwin-snapshot-20140523-1.original/winsup/cygwin/grp.cc2014-05-23 12:31:13.0 +0200 +++ cygwin-snapshot-20140523-1.patched/winsup/cygwin/grp.cc 2014-05-26 15:08:37.542897300 +0200 @@ -656,11 +656,11 @@ groups[cnt] = grp->gr_gid; ++cnt; } - *ngroups = cnt; if (cnt > *ngroups) ret = -1; else ret = cnt; + *ngroups = cnt; syscall_printf ( "%d = getgrouplist(%s, %u, %p, %d)", ret, user, gid, groups, *ngroups); Regards, Denis Excoffier. -- 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
timeout in LDAP access
Hello, I’ve exercised ‘getent' a little bit those days (with 'db_enum: all’ in /etc/nsswitch.conf), and it seems to me that the timeout ‘tv' (3 seconds, in ldap.cc) is probably too small for servers not so quickly responsive or with many (50, fake or real) users around (see the call to ldap_get_next_page_s()). 300 seconds should be enough i suppose. Also it is a pity that LDAP_TIMEOUT is not announced to the user (except under strace: 0x55). I don’t know the general policy for timeouts, but i consider that the user would like to be informed when the passwd/group list was truncated. Another (unrelated and less important) problem is that 'getent' happily produces lines with some extra ‘:’, in particular when the gecos field itself contains ‘:’. Regards, Denis Excoffier. -- 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: timeout in LDAP access
Hi Corinna, On 2014-06-17 12:00, Corinna Vinschen wrote: > > So I expect an LDAP_SUCCESS with ldap_count_entries() == 0 and then > repeat the request. But the code doesn't expect LDAP_TIMEOUT in this > case. Do I have to handle LDAP_TIMEOUT here as well? LDAP_TIMEOUT can occur there. I can even suppose it occurs more frequently for the _last_ 100-sid chunk (eg there are 5868 users in a domain, and timeout occurs after 5800 and the last 68 get lost). But it can also occur after 27 chunks while about 35 users are still to be read in a given domain (yes, that makes about 352700 users in a single domain). I’m pretty convinced today that 300 is more than enough, and that with 3, only one or two timeouts are to be expected for an AD with 50 users and not so many domains (50 or 100). The flaw is that as soon as the first timeout occurs, the whole rest of the current domain is skipped, which can be much in some cases. ldap_get_next_page_s() should perhaps deserve a second chance (with timeout 30s). After all, this function is called 3527 times (for the same domain). Also a simple observation: if LDAP_TIMEOUT is not to be expected, what is the use of this timeval* parameter in ldap_get_next_page_s()? > I'm wondering if the timeout, at least for enumerating accounts, should > go away entirely. In case of a connection problem this could result in > a hang for about 2 minutes by default I think (LDAP_OPT_PING_LIMIT). I think i like this (it it works). But in this case, it will not resume to the next domain, and the whole operation (eg getent) is interrupted? Regards, Denis Excoffier. -- 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: gecos from AD? (was Re: timeout in LDAP access)
On 2014-06-17 12:30, Corinna Vinschen wrote: > On Jun 17 12:00, Corinna Vinschen wrote: >> On Jun 16 22:39, Denis Excoffier wrote: >>> Another (unrelated and less important) problem is that 'getent' >>> happily produces lines with some extra ‘:’, in particular when the >>> gecos field itself contains ‘:’. >> >> Wow, that *is* important. All fields returned from the server have to >> get their colons converted to commas. I'll fix that. > > While we're at it... do we really need the gecos info? Cygwin fills > out this field with the Windows username and SID info for internal > purposes, and then adds the gecos info from AD. However, it's just > informational and usually only used by the finger(1) tool. The gecos field from AD seems to be _prepended_ (not appended) to the username + SID. In any case, it may represent some information with high added value (like user real name or e-mail address, depending on local rules of course). I would not vote for removing it. Why is it so clear that the ‘:’ should be replaced by a comma? Here, we have situations where it contains something like « Owner: Albert Einstein ». An underscore could be more appropriate. There is something more important: i’ve written in one of my previous messages that when ‘:’ occurs in gecos, the resulting ‘passwd’ file under ‘getent’ will contain more ‘:’ than expected, but this is incorrect. In fact (and i would like someone to try it), when ‘:’ is found within the gecos field, ‘getent’ does not show the last (homedir) field, and the count of ‘:’ is still correct. The problem might not be in getent after all. Regards, Denis Excoffier. -- 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: gecos from AD? (was Re: timeout in LDAP access)
On 2014-06-17 14:51, Corinna Vinschen wrote: > On Jun 17 12:30, Corinna Vinschen wrote: >> On Jun 17 12:00, Corinna Vinschen wrote: >>> On Jun 16 22:39, Denis Excoffier wrote: >>>> Another (unrelated and less important) problem is that 'getent' >>>> happily produces lines with some extra ‘:’, in particular when the >>>> gecos field itself contains ‘:’. >>> >>> Wow, that *is* important. All fields returned from the server have to >>> get their colons converted to commas. I'll fix that. > > On second thought, removing colons should only occur for gecos. The > other fields shouldn't contain colons anyway since their content has to > be POSIX-compatible anyway. > > So, either I add code to remove the colons from the gecos field … This. > > >> While we're at it... do we really need the gecos info? Cygwin fills >> out this field with the Windows username and SID info for internal >> purposes, and then adds the gecos info from AD. However, it's just >> informational and usually only used by the finger(1) tool. >> >> Shall I just remove fetching the gecos fields from AD entirely? > > ... or that. Not that. Denis Excoffier. -- 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: timeout in LDAP access
On 2014-06-18 20:01, Corinna Vinschen wrote:
> On Jun 18 10:33, Corinna Vinschen wrote:
>>
>>
>> The idea I was proposing was just to drop all attempts to seconds guess
>> how fast a DC replies. We're going to use LDAP with default settings
>> and that's it. Default settings means, every operation times out after
>> the default timeout period of 120 seconds, which should really be
>> sufficient.
>
> I'm not quite sure I understand the effect of all the timeout values in
> LDAP entirely correctly and the API documentation leaves quite a bit to
> be desired.
>
> For the time being I raised the timeout to 30 seconds, and colons in
> the gecos field are converted to semicolons. I uploaded a new developer
> snapshot to http://cygwin.com/snapshots/ Please give it a try.
I tried the last snapshot. First the ${tr ‘:’ ‘;’} operation works perfectly,
and the last field (of 'getent passwd' is now always the homedir. You may
like to correct a typo in the ChangeLog, should be ‘semicolon’ instead of
‘comma’.
Also, i tried with several different values for CYG_LDAP_TIMEOUT. With 45s, 60s,
115s and 125s, i obtained no timeout (outputing 50 users takes 1h).
I tried 3 times with 30s and got once with no timeout, once with one timeout
and once with 3 timeouts (ie one timeout for 3 domains).
In any case, if you wish to switch to timeout=120s is ok for me. The PageSize
(100) could also be changed?
Here two remarks about timeouts:
1) for most of the 100-sid chunks, the high timeout is not used, therefore
the global penalty in delay is not so high. And perhaps a 120s timeout is high
enough so that when it is met, we could abandon not only the current domain,
but also the whole search?
2) if value of timeout is not high enough (i have no figures…), timeout may
occur when the PC is in fact occupied with other tasks (eg antivirus scanning
or something else), unrelated to network delays or server latencies.
Regards,
Denis.
--
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: timeout in LDAP access
On 2014-06-23 11:09, Corinna Vinschen wrote: > On Jun 19 19:53, Denis Excoffier wrote: > > Do you really *want* to enumerate 500K users when accessing the DCs > remote over a slow DSL line? Isn't this a situation in which you'd > rather like to avoid enumerating accounts or restrict it to an > essential subset? That's what db_enum would be good for. IMHO the line is not especially slow. Instead, the server (and occasionally the client) is clobbered sometimes. For example it seems more difficult (ie timeout occurs more frequently) for a server to output the last sid’s in a domain than to output a full PageSize of results. Personally i don’t *want* to use /etc/nsswitch.conf at all. What bothers me is that the user does not get any indication of a timeout (and several successive and unrelated timeouts may be met in a single invocation of getent). Therefore even if all servers are up, the user has no means to know that the list is exhaustive. If the timeout occurs for the last chunk this is not so important, but if the timeout occurs in the middle it may be. That is the difference between a large timeout and a timeout, say, too accurate. > I'm rather inclined to revert the timeout for single account access to a > smaller value again (5 or 10 secs) and introduce a second, longer > timeout value for enumeration (60 secs, for instance). This is fine. I suppose timeout will rarely occur when a single result is expected (and the server is up). I tried ‘getent passwd sid’ a couple of times and the result has always been instantaneous. > > I've applied a patch to ldap.cc to this effect. Would you mind to give > it a try? 60s is okay. Today i got several timeouts while enumerating passwd with a timeout of 60s. Last Friday, all my tests with timeout >= 45s produced no timeout. Perhaps the servers are less used when the week-end is not too far... > >> The PageSize >> (100) could also be changed? > > Yes, the pagesize can be changed, too. I'm just not sure about the > consequences. In my pretty small AD environment 100 seemed to be a > good compromise in terms of performance and size (as I mentioned, just > 4 KB per page). Less than 100 slowed down getent noticably, more than > 100 didn't provide a visible speedup. > > Can you test in your big environment in how far raising this value > changes the performance and the chance for timeout? Since the load is > on the server, it should be pretty fast in collecting the next X SIDs. > I'm just a bit concerned about the (unnecessary?) network traffic this > might generate. I tried pagesize=50,200,400, with, as you said, no notable difference. With 400, i can suppose it is a little faster (10% less than usually) and a little longer with 50. 1 or 2 timeouts always (i also tried with timeout=120s). No big difference really. > >> Here two remarks about timeouts: >> 1) for most of the 100-sid chunks, the high timeout is not used, therefore >> the global penalty in delay is not so high. And perhaps a 120s timeout is >> high >> enough so that when it is met, we could abandon not only the current domain, >> but also the whole search? > > Would that be really a bright idea? Assuming your ADs (and their DCs) > are in different remote locations, One of those connections being down > would disable enumerating other domains. It would be a means to have getent 'depend' on a unique timeout. > >> 2) if value of timeout is not high enough (i have no figures…), timeout may >> occur when the PC is in fact occupied with other tasks (eg antivirus scanning >> or something else), unrelated to network delays or server latencies. > > No timeout is prepared for a CPU being 100% in use :| My experience is that if antivirus considers that some job has to be done urgently, everything else freezes. I have to cope with that. Well. My (current) opinion is: * def_tv=5, enum_tv=60 or 120 * pagesize=100 is fine * perhaps getent could be augmented to enumerate domains (getent domain) and also to enumerate sids in a given domain? That way, the timeout, when it occurs, is for a single domain. And this would perhaps be more useful than the full ‘getent passwd’ for a large database. Thank you Corinna for your time with this. Denis Excoffier. -- 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: timeout in LDAP access
On 2014-06-25 12:15, Corinna Vinschen wrote:
>> Stay tuned. I'm rewriting the LDAP access code to perform all critical
>> LDAP calls in interruptible threads. The Windows LDAP calls don't
>> provide any kind of synchronization, only timeouts. I hoped to get away
>> with short timeouts but it seems I hoped in vain.
>>
>> So the next iteration of this code will not use any timeout other than
>> the default LDAP network timeout of 2 minutes, but the calls will be
>> interruptible by signals.
>>
>
> No more artificial timeouts, but the LDAP calls will be interruptible by
> a signal now.
>
> Also, if an error occurs during ad enumeration, getpwent/getgrent will
> return NULL with errno set accordingly.
>
> Please test,
I did. Again, i instrumented ldap.cc by replacing all debug_printf() calls
with system_printf() because my /usr/bin/strace does not work. Again, i
tested with ‘getent passwd > result’ and 'db_enum: all’.
I got the following message:
[ldap_init] getent 6024 cyg_ldap::connect_non_ssl: ldap_bind(xx.zzz) 0x51
and getent stops after the 376000 users in my own domain. No timeout occurred
but the enumeration was stopped by LDAP_SERVER_DOWN (0x51) [the xx.zzz
domain name has been edited here but it was completely new to me, never seen
before].
Also, there was a large delay (more than 2 min, say at least 8 minutes) between
the end of output and the end of getent. I got one single system_printf
message (see above).
More than that, i added system_printf("starting open in domain %W", domain)
immediately at the beginning of cyg_ldap::open, and run ‘getent passwd’ now
during
one minute (wait 60s, then Control-C). I got 1080 ‘starting open in domain
(null)’
messages on stderr and 1016 normal passwd entries on stdout. The discrepancy
1016 vs 1080 is ok because stdout was not properly flushed out.
It seems that
- domain is printed as ‘(null)’? Strange
- there are as many open() calls as passwd entries in the output? Also strange
- EIO (or equivalent) is produced for LDAP_SERVER_DOWN, it probably should be
better if this were not the case?
I suppose it will need more testing, but i’m currently unavailable for tests,
by the way until Friday 08:00 UTC.
Regards,
Denis Excoffier.
--
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: timeout in LDAP access
On 2014-06-25 23:13 Corinna Vinschen wrote:
>
> You asked for errors being propagated up the chain to the
> getpwent/getgrent calls and that's exactly what happens now. There are
> a lot of LDAP error codes. How is Cygwin supposed to handle every one
> of them? Do we need a list of ignorable and non-ignorable error codes?
I don’t know. IMHO:
- a server which is down can be ignored (unless explicitly requested)
- a timeout, when some output has already been received, must be reported
- all servers should be treated independently since they are independent
For the time being, i have added LDAP_SERVER_DOWN in map_ldaperr_to_errno
at the same place as LDAP_SUCCESS.
>
>> Also, there was a large delay (more than 2 min, say at least 8 minutes)
>> between
>> the end of output and the end of getent. I got one single system_printf
>> message (see above).
>
> I can't observe this. It needs debugging in your environment so I know
> which part of the source is responsible for this delay under what
> circumstances.
I forgot to test it again. I’ll do it soon.
>
>> More than that, i added system_printf("starting open in domain %W", domain)
>> immediately at the beginning of cyg_ldap::open, and run ‘getent passwd’ now
>> during
>> one minute (wait 60s, then Control-C). I got 1080 ‘starting open in domain
>> (null)’
>> messages on stderr and 1016 normal passwd entries on stdout. The discrepancy
>> 1016 vs 1080 is ok because stdout was not properly flushed out.
>
> 60 seconds for 1016 user entries? That sounds incredibly slow.
I’m pretty sure that this is due to the non-buffering
of stderr. In fact, system_printf() is incredibly slow ;-)
>> - there are as many open() calls as passwd entries in the output?
>
> The open function is called for every account, but that doesn't mean it
> really needs opening. That's what the early return is for. The code
> starts like this:
>
> [...]
>
> Did you add the system_printf before the "/* Already open? */" comment,
> by any chance?
You’re right. It was before. Now i have it after and there is only one
such message for the primary domain.
However, for the non-primary domains the result is the same: i get as
many cyg_ldap::open()s as accounts. Even more strange, for all these open’s
(except the first one) the domain variable is printed as (null). Perhaps
something uncontrolled within pg_ent::enumerate_ad()? Simple suggestion, i
was not able to understand the logic there.
>
> Corinna
Denis.
--
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: timeout in LDAP access
On 2014-07-07 13:07, Corinna Vinschen wrote: > > For enumerating a non-primary domain, I get exactly two calls to > cyg_ldap::open which actually do a connect. The first call opens the > domain for enumeration. The second call opens the primary domain (NULL) > to fetch the POSIX offset value for the foreign domain (see my document > explaining the POSIX offset stuff), unless the application or one of > its parent processes already fetched the POSIX offset for this domain. > > I don't observer any further calls to connect in this scenario. > > In your preliminary documentation (your message dated 2014-06-25, please correct "seet" in it), trustPosixOffset is "some arbitrary 32 bit value", ie including 0. In your code (fetch_posix_offset), td->PosixOffset is used to record the value and also (when 0) to record that the value has still not been fetched. I have encountered this case in real life. The domain admins have set the trustPosixOffset of the secondary domain to zero. This value is therefore never recorded and the cldap->open occurs again and again. Hope this helps. Regards, Denis Excoffier. -- 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: timeout in LDAP access
On 2014-07-09 12:12 Corinna Vinschen wrote: >> >> I have encountered this case in real life. The domain admins have set >> the trustPosixOffset of the secondary domain to zero. This value is therefore >> never recorded and the cldap->open occurs again and again. > > Ouch. Why on earth are admins doing this? There's no way to > workaround this reliably. > Reliably i don’t know. I’ve modified uinfo.cc in order that the special value for td->PosixOffset is no longer 0. Taking into account that LDAP_SERVER_DOWN is now recognized, my ‘getent passwd’ executes gracefully in 40 minutes (instead of 60) and ‘getent group’ in 25 minutes (instead of 90). Also quicker is ‘mkpasswd -d secondary_domain’ of course. Patch attached. Regards, Denis Excoffier. posixoffset.patch 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: timeout in LDAP access
On 2014-07-14 15:48 Corinna Vinschen wrote: > On Jul 14 11:51, Corinna Vinschen wrote: >> On Jul 12 15:39, Denis Excoffier wrote: >>> On 2014-07-09 12:12 Corinna Vinschen wrote: >>>>> >>>>> I have encountered this case in real life. The domain admins have set >>>>> the trustPosixOffset of the secondary domain to zero. This value is >>>>> therefore >>>>> never recorded and the cldap->open occurs again and again. >>>> >>>> Ouch. Why on earth are admins doing this? There's no way to >>>> workaround this reliably. >>>> >>> Reliably i don’t know. I’ve modified uinfo.cc in order that the special >>> value >>> for td->PosixOffset is no longer 0. Taking into account that >>> LDAP_SERVER_DOWN >>> is now recognized, my ‘getent passwd’ executes gracefully in 40 minutes >>> (instead of 60) and ‘getent group’ in 25 minutes (instead of 90). Also >>> quicker >>> is ‘mkpasswd -d secondary_domain’ of course. Patch attached. >> >> That won't work. It works around your immediate problem by defining >> a non-0 start value, no doubt about that, but it doesn't fix the >> underlying problem. >> >> A POSIX offset of 0 is bad. If other trusted domains have no functional >> POSIX offset value, but are set to 0 instead, they won't have different >> UID values for accounts of different domains. Two users from different >> domains, both with RID 1000 will both have UID 1000 in Cygwin. Also, >> the lower UID numbers are reserved for special accounts. >> >> There is no guarantee that there won't be a collision at some point of >> the 32 bit UID spectrum, but a POSIX offset of 0 will almost guarantee >> the collision. >> >> There are two ways to workaround that. >> >> - The better solution is to inform your IT of the problem. >> >> - The not so well one is to enhance /etc/nsswitch.conf to allow to >> define POSIX offsets for domains indepedent of the AD setting. > > I tried the third solution for the time being, which is, generating the > fake POSIX offset a bit differently. Fake offsets are a bit dangerous > in that there's no guarantee that you get a stable mapping between SID > and UID/GID, but it's *hopefully* a border situation we're trying to > workaround. Please give the latest developer snashot from > http://cygwin.com/snapshots/ a try. Tried and it works as expected. However there is a design bug. Suppose you have a SID from a non-primary domain (with PosixOffset=0). When you enumerate, you get a PosixOffset that takes into account the previously encountered secondary domains with PosixOffset=0, say you get UNIX_POSIX_OFFSET-3*0x0080 But you can also jump directly to the non-primary domain of this SID, eg by ‘getent passwd SID’. In this case you get UNIX_POSIX_OFFSET-0x0080. In fact, real code is a little bit more complex, but you get the point: ‘getent passwd’ and ‘getent passwd SID’ will not give the same UID for a given SID, the AD remaining unmodified. Independently, i’m still not sure we have to workaround IT "madness" at all. First, IT people might set PosixOffset to 1 for each domain and you cannot catch this kind of alternate madness. Also, be sure that if some user someday suffers from a duplicate UID situation, this will be reported to them and hopefully addressed (or not because this might be expected), but most probably for a single domain. We have to live with PosixOffset=0. Yet, under the assumption that PosixOffsets are not modified by Cygwin, previous uinfo.cc (snapshot dated 20140709) is not so efficient when PosixOffset=0 (eg too many connect’s), and i think my patch makes a better Cygwin than with no patch. Probably it can also be improved to remove the special value. Regards, Denis Excoffier. -- 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: timeout in LDAP access
On 2014-07-16 15:51, Corinna Vinschen wrote: > It occured to me that there's another way to do that. The problem > you're mentioning above could be alleviated if the first Cygwin process > in a process tree fetches all POSIX offsets of all trusted domains right > at the start, rather than fetching the POSIX offsets only on demand by > whatever process needs it. This would slow down the startup of the > first process slightly (one LDAP request per trusted domain, but only > asking your primary DC), but this would have two advantages: > > - After fetching all POSIX offsets, we could filter out all POSIX > offsets which don't make sense. These would be set using the fake > offset setting mechanism. "No sense" would include offsets < 0x11 > or offsets > 0xff00. If the first process in the tree > > - The UID/GID values would be stable throughout the process tree. > > - The UID/GID values would be stable systemwide when utilizing cygserver. > > That's a bit of work, but Cygwin 1.7.31 will still come without this > AD integration code anyway, so we still have time to turn everything > upside down. I buy this of course, but i’m still not convinced that we have to workaround. After all, since i don’t care the other domains in my daily work, i’m not affected at all. Most of the users will never be affected i suppose. And if Cygwin happens to circumvent a null posixOffset by providing its own, there will be even less chances for collisions and for collisions being reported. But we can consider the other way and for that i will use a comparison: using special characters (like ‘\n’) gratuitously in the middle of filenames is usually considered as a bad practice, but always possible by doing ‘char *filename = "a\nb"; fopen(filename, "w")’. Now, once this file is created, you can use ‘ls’ in the folder. Do you think ‘ls' should respect user decision and display the raw \n in its output or try to workaround by using some substitution character (like ‘?’) in order not to wrap at unexpected locations? The answer is that ‘ls’ substitutes by default, but also provides a full group of related options to change this behavior (--quoting-style=WORD, --hide-control-chars). Of course, adding options (eg in nsswitch.conf) to orientate the assignment of posixOffsets to various substitutes would be useless. Even assigning the null posixOffsets to non-null values, i’m not convinced of. Denis Excoffier. -- 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: timeout in LDAP access
On 2014-07-28 11:21, Corinna Vinschen wrote: > Ping? > > On Jul 18 21:18, Corinna Vinschen wrote: >> >> We really should do that to avoid collisions with system accounts, IMHO. >> >> But maybe we should handle it as a border case of a border case, and >> reliably. Rather than using the default fake mechanism, what if >> we use default offsets for the two cases: >> >> Case 1: posix offset is < 0x10 ==> Enforce posix 0ffset 0xfe8 >> Case 2: posix offset can't be fetched (this points to a local user >>having no access to this kind of domain information) >> ==> Enforce posix offset 0xfe00. >> >> This would result in potential collisions in very rare border cases, >> but it would result in reliable mappings throught all processes. >> And, the complexity would be quite small. > > any feedback on this one? Shall I create a snapshot with a matching > patch? I have nothing to add except that i am a great fan of cygwin snapshots in general, and i suppose that if several posix offsets are set to 0, it is a minor problem if all of them get replaced by the same 0xfe8. Regards, Denis Excoffier. -- 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
suggestion about math.h
Hello, Perhaps the values of some constants are not as accurate as they should be? See also M_LN2LO and M_LN2HI. diff -uNr cygwin-snapshot-20140807-1-original/newlib/libc/include/math.h cygwin-snapshot-20140807-1-patched/newlib/libc/include/math.h --- cygwin-snapshot-20140807-1-original/newlib/libc/include/math.h 2014-08-07 18:26:21.0 +0200 +++ cygwin-snapshot-20140807-1-patched/newlib/libc/include/math.h 2014-08-07 19:31:51.0 +0200 @@ -569,14 +569,14 @@ #ifndef __STRICT_ANSI__ #define M_TWOPI (M_PI * 2.0) -#define M_3PI_42.3561944901923448370E0 -#define M_SQRTPI1.77245385090551602792981 +#define M_3PI_42.3561944901923449288E0 +#define M_SQRTPI1.77245385090551602729817 #define M_LN2LO 1.9082149292705877000E-10 #define M_LN2HI 6.9314718036912381649E-1 -#define M_SQRT31.73205080756887719000 +#define M_SQRT31.73205080756887729353 #define M_IVLN100.43429448190325182765 /* 1 / log(10) */ #define M_LOG2_E_M_LN2 -#define M_INVLN21.4426950408889633870E0 /* 1 / log(2) */ +#define M_INVLN21.4426950408889634074E0 /* 1 / log(2) */ /* Global control over fdlibm error handling. */ Regards, Denis Excoffier. -- 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
modification time of standard input is wrong
Hello,
Under Cygwin 1.7.1-1, i have created the small program (see below),
to print the modification time of the standard input. In the case where
the stdin is a pipe (or the terminal), i expect the result to be more
or less the current time. But the time printed in this case is
invariably the modification time of /dev/null.
This has some impact in gzip and further, in tar.
Thank you for your help. See below for the details.
Denis Excoffier.
-
#include
#include
#include
//
int main() {
//
struct stat s;
if (fstat(fileno(stdin), &s) != 0) {
fprintf(stderr, "error fstat\n");
} else {
struct tm *tm = localtime(&s.st_mtime);
if (tm) {
printf("%u\n", s.st_mtime);
printf("%04u-%02u-%02u %02u:%02u:%02u\n", 1900 + tm->tm_year,
1 + tm->tm_mon, tm->tm_mday, tm->tm_hour, tm->tm_min, tm->tm_sec);
} else {
fprintf(stderr, "error localtime\n");
};
};
return(0);
};
-
% uname -s
CYGWIN_NT-5.1
% setenv TZ UTC
% gcc -o myprog myprog.c
% ./myprog < myprog.c
1268727969
2010-03-16 08:26:09
% ./myprog
1164931200
2006-12-01 00:00:00
% ls -lgG --full-time /dev/null
crw-rw-rw- 1 1, 3 2006-12-01 00:00:00.0 + /dev/null
% tar czf - /etc/passwd | (od --skip-bytes=4 -l -N4; cat > /dev/null)
tar: Removing leading `/' from member names
004 1164931200
010
%
--
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: modification time of standard input is wrong
On Wed, Mar 17, 2010 at 12:56:12PM +0100, Corinna Vinschen wrote: >> >> What impact? I don't think there is any standard which requires a non >> filesystem based stream to have a current timestamp and a tool relying >> on that might be broken. All our streams which are not backed by a >> filesystem w/ valid timestamps have an artificial timestamp of >> 2006-12-01 00:00:00. The file `algorithm.doc' within the gzip distribution states that "If input does not come from a regular disk file, the file modification time is set to the time at which compression started.". This has been reported to the `bug-gzip' mailing list (see http://lists.gnu.org/archive/html/bug-gzip/2010-03/msg0.html). In his answer, Eric Blake suggested that the bug might be in cygwin1.dll. Regards. Denis Excoffier. -- 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
readshortcut: print Target in raw format
Hello, On my Cygwin system (XP) i have (probably like most of you) the following commands: 1) readshortcut.exe, from the package cygutils-1.4.2 2) SHORTCUT.EXE, from %windir%/system32 (or equivalent) They are both consistent: in case of a `Target' that contains an environment variable, the variable is resolved, for example: % readshortcut -tfw X-Cygwin.bat.lnk Target: C:\Users\me\me\cygwin2010b\Cygwin.bat % /cygdrive/c/winnt/system32/SHORTCUT.EXE -u t X-Cygwin.bat.lnk Target: C:\Users\me\me\cygwin2010b\Cygwin.bat However, in the `Properties' of the Shortcut, i can read in the Target cell: `%myhome%\cygwin2010b\Cygwin.bat' I would have preferred readshortcut.exe to show this raw path, with the environment variable %myhome% still unresolved. So i went into cygutils-1.4.2/src/readshortcut/readshortcut.c and discovered that, if the last argument of GetPath() is set to `SLGP_RAWPATH' (this is ok), the value of SLGP_RAWPATH is obtained from `#include ' (this is still ok), but it is redefined later with `#define SLGP_RAWPATH 0' (this is *not* ok, it should be 4). It seems that the intentions of the original writer were to print the raw path, but someone later changed that to be consistent with SHORTCUT.EXE (or due to some other reason). Please modify readshortcut.exe in order to be able to really print the raw path (e.g. with an extra option). Thanks in advance. Regards. Denis Excoffier. -- 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
enlarge MAXSYMLINKS
Hello, I use Cygwin 1.5.25-15 (with all packages installed), especially i'm currently creating symbolic links. My filesystem is NTFS, my symlinks are created as "Windows shortcuts" (see winsymlinks in the CYGWIN environment variable, though i don't use the variable, but this is the default). I've created 36 links: 0->1, 1->2 ... 8->9, 9->a, a->b, b->c, c->d, up to y->z and z->/etc/passwd (a plain file). Now, `wc q` works as expected (i.e. counts the number of lines/words/ chars in /etc/passwd), but `wc p` produces "Too many levels of symbolic links". Well it may be that MAXSYMLINKS is defined to be 10 in cygwin kernel. But, cygwin-1.5.25-15/newlib/libc/sys/rtems/sys/params.h indicates "#define MAXSYMLINKS 32", a reasonable value. Where does this value "10" come from? Is there any possibility to enlarge the value of 10 in order to reach e.g. 32 as expected? The value 10 is definitely too low for me, a value 20 (like in Solaris) would be better. Thank in advance for your help, Denis Excoffier. -- 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: enlarge MAXSYMLINKS
Again about symbolic links, here is some new inputs: 1) MAXSYMLINKS is no longer used in modern Cygwin's; indeed, cygwin-1.5.25-15 uses MAX_LINK_DEPTH and cygwin-1.7.0-42 uses SYMLOOP_MAX; both are set to 10 (in ./winsup/cygwin/path.h for 1.5 and in ./winsup/cygwin/include/limits.h for 1.7) 2) whether the filesystem is NTFS or not makes no difference; whether the symlinks are created using winsymlinks or nowinsymlinks makes no difference 3) the only clean way to make cygwin1.dll accept a chain of 32 symlinks (instead of 10) is through recompilation 4) for those interested in not-so-clean items, the following may also work - for 1.5.25-15 (this one i have tested) - cd /usr/bin - cat cygwin1.dll | perl -pi -e 's|\203\275\224\371\377\377\012| \203\275\224\371\377\377\040|' > cygwin1.dll.new - check that cksum before is 3685478250 - check that cksum after is 3302069714 - set the appropriate permissions/owners/groups etc. on cygwin1.dll.new - from outside Cygwin (eg. from Windows): - rename cygwin1.dll into cygwin1.dll.old - rename cygwin1.dll.new into cygwin1.dll - for 1.7.0-42 (this one i have not tested, please report if fails) - same as before, with the -e expression replaced by -e 's|\203\275\344\355\377\377\013| \203\275\344\355\377\377\041|' - how you can find these strings yourself: 1) either - objdump -d cygwin1.dll - look for path_conv::check(...) - search into those 1000 lines, trying to make the names to match - try 2) or - recompile with SYMLOOP_MAX set to 10 (result1) - recompile with SYMLOOP_MAX set to 10 (result2) - recompile with SYMLOOP_MAX set to 32 (result3) - compare result1 and result2 to discover the impact of current time in the result - compare result1 and result3 and eliminate the impact of current time - (make sure that compilation options are the same as originally) 5) i would also make the following suggestions: 1) to enhance cygcheck to report whether a given symlink is implemented as a Windows'shortcut or as an adhoc Cygwin symlink (although this can be seen easily from outside Windows) 2) to use "#define SYMLOOP_MAX 32" in future Cygwin-1.7 Hope this helps, Denis Excoffier. -- 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/
1.7.0-62: segfault when PATH is not set
Hello, I've installed all the Cygwin-1.7.0 packages uptodate, on my Windows XP machine. I do experience a segmentation fault whenever i launch a program when the PATH is not set. When PATH is badly set (but set), nothing happens (and the result is OK). See below how to reproduce. When i switch back to 1.7.0-61, the problem disappears. On a Windows 2000 machine, the same happens. Thank you to spend a little time to take my problem into consideration. Denis Excoffier. jupiter% uname -a CYGWIN_NT-5.1 JUPITER 1.7.0(0.214/5/3) 2009-10-03 14:33 i686 Cygwin jupiter% date --version | head -1 date (GNU coreutils) 7.0 jupiter% env --version | head -1 env (GNU coreutils) 7.0 jupiter% env - PATH=/usr/bin /usr/bin/date Fri Oct 16 17:26:37 RDT 2009 jupiter% env - PATH=/nonexistent /usr/bin/date Fri Oct 16 17:26:37 RDT 2009 jupiter% env - PATHOS=/nonexistent /usr/bin/date Segmentation fault (core dumped) jupiter% cat date.exe.stackdump Exception: STATUS_ACCESS_VIOLATION at eip=610BFBE1 eax=0001 ebx=006700F0 ecx=8000 edx= esi= edi=006700F0 ebp=0022CD18 esp=0022CCC0 program=C:\Users\me\cygwin2009f\bin \date.exe, pid 3056, thread main cs=001B ds=0023 es=0023 fs=003B gs= ss=0023 Stack trace: Frame Function Args 0022CD18 610BFBE1 (8000, , , 6120DD35) 0022CD38 610BFE83 (, 0002, 2D465455, 610F0038) 0022CDB8 610C1A7F (, 0022CDF0, 610066F0, 7FFDE000) End of stack trace -- 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.0-62: segfault when PATH is not set
On 2009-10-19 11:36, Corinna Vinschen wrote: On Oct 17 04:33, Denis Excoffier wrote: Hello, I've installed all the Cygwin-1.7.0 packages uptodate, on my Windows XP machine. I do experience a segmentation fault whenever i launch a program when the PATH is not set. When PATH is badly set (but set), nothing happens (and the result is OK). See below how to reproduce. When i switch back to 1.7.0-61, the problem disappears. On a Windows 2000 machine, the same happens. Thank you to spend a little time to take my problem into consideration. Denis Excoffier. jupiter% uname -a CYGWIN_NT-5.1 JUPITER 1.7.0(0.214/5/3) 2009-10-03 14:33 i686 Cygwin jupiter% date --version | head -1 date (GNU coreutils) 7.0 jupiter% env --version | head -1 env (GNU coreutils) 7.0 jupiter% env - PATH=/usr/bin /usr/bin/date Fri Oct 16 17:26:37 RDT 2009 jupiter% env - PATH=/nonexistent /usr/bin/date Fri Oct 16 17:26:37 RDT 2009 jupiter% env - PATHOS=/nonexistent /usr/bin/date Segmentation fault (core dumped) Strange. I can't reproduce this: $ env - PATHOS=/dqd /usr/bin/date Mon Oct 19 11:26:46 WEDT 2009 $ env - PATHOS=/nonexistent /usr/bin/env PATHOS=/nonexistent SYSTEMROOT=C:\Windows WINDIR=C:\Windows You're right, it seems that LC_CTYPE is also involved in this. Please try under sh: $ export LC_CTYPE= $ env - PATHOS=/nonexistent /usr/bin/date Mon Oct 19 13:12:40 RDT 2009 $ export LC_CTYPE=dummy $ env - PATHOS=/nonexistent /usr/bin/date Segmentation fault (core dumped) $ export LC_CTYPE=C $ env - PATHOS=/nonexistent /usr/bin/date Mon Oct 19 13:12:40 RDT 2009 $ export LC_CTYPE=fr_FR.ISO-8859-15 $ env - PATHOS=/nonexistent /usr/bin/date Segmentation fault (core dumped) $ export LC_CTYPE=dummy $ env - PATHOS=/nonexistent /usr/bin/date Mon Oct 19 13:12:41 RDT 2009 $ env - PATHOS=/nonexistent /usr/bin/env PATHOS=/nonexistent SYSTEMROOT=C:\WINNT WINDIR=C:\WINNT Hope this helps. Regards. Denis Excoffier. -- 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.0-62: segfault when PATH is not set
On 2009-10-19 21:18, Denis Excoffier wrote: $ export LC_CTYPE=dummy $ env - PATHOS=/nonexistent /usr/bin/date Mon Oct 19 13:12:41 RDT 2009 $ env - PATHOS=/nonexistent /usr/bin/env PATHOS=/nonexistent SYSTEMROOT=C:\WINNT WINDIR=C:\WINNT Oops, bad redact, the first line in the last example should read like the first one: $ export LC_CTYPE= Sorry for this. Denis Excoffier. -- 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: mv: Device or resource busy
#x27;s (ie *xxx, see above) will expose the failures fi exit -- Figures: i just tested with xpdf.exe (1.3Mb), and it failed 19 times out of 20. i just tested with banner.exe (8192b), and it failed 3 times out of 20. i just tested with diff.exe (105kb), and it failed 20 times out of 20. My environment is: I have two Cygwin boxes, the first is a Fujitsu laptop with XP SP3, the second is an HP tower with XP SP2. Both with an NTFS disk (150Gb), all the tests have been performed within this NTFS disk, under (unless otherwise mentioned) Cygwin 1.7.0-62, with all the packages installed. I also never noticed any change in the inodes (see above `ls -i'). My interpretation of the symptoms is as follows (ie if i had to reproduce this behavior inside a program of my own, i would do the following): Let's suppose we only have executable (755) files beginning with MZ, on my first Cygwin box. In my opinion, each slot in a directory would some room for a boolean variable initially set to 0, meaning "this entry is not executable or i don't know". This boolean would be used only in case of a `mv' command which would use this particular directory slot as the first parameter. When the `mv' command is launched, two cases: - if the boolean is set to 1 (meaning: "this entry has been established to be executable"), the command would be performed normally, the file is moved, the directory entry remains with the boolean set to 1, with no file inside (since the `mv' succeeded) - if the boolean is set to 0, two processes would be running concurrently: - the normal process of mv, which (if successful) finally has to rename() file1 - an unknown process which reads the content of file1, updates the access time of file1, turns the boolean into 1, and takes more time if the content of file1 (or the size indicated in the directory slot, who knows?) is large and less time if the content of file1 is small; Also: this unknown process starts after having received the 'y' in case of `mv -i'. If the winner of this race is the normal process of mv, we get: Device or resource busy. If the winner is the unknown process, the mv is performed normally. In any case, the boolean is set to 1. The above mechanism does not exactly seem 100% correct, since we can observe that the access time is also updated when the boolean has previously been set to 1: the unknown process would probably need to be launched at each instance of (this kind of) mv, but must return very quickly if the boolean is already set to 1. Help! How to solve this? How to make my first box behave like the second one (ie never fail)? At least, did you manage to reproduce this? Thank you for your time. Denis Excoffier. P.S. For your information and to be the most comprehensive, at least two classical packages (`tcl8.6b1' and `openssl-1.0.0-beta3') have their `make install' to fail with exactly this error (to be exact, the `make install' from the tcl package does not fail since the error is not caught, but the final copy is not performed). -- 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.0-62: segfault when PATH is not set
On 2009-10-19 21:47, Corinna Vinschen wrote: On Oct 19 21:18, Denis Excoffier wrote: Hope this helps. It does. The value of $PATH is used without checking if $PATH exists. I fixed that in CVS. Thank you. Let's wait until 1.7.0-63 now. In the same spirit, i discovered that `cygcheck -s' does not behave correctly (ie is prematurely interrupted) if COMSPEC is not set to the appropriate value (C:\WINNT\system32\cmd.exe or equivalent), or is not set at all. This fact would perhaps deserve a short notice in some man page. Regards, Denis Excoffier. -- 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] TEST RELEASE: Cygwin 1.7.33-0.1
On 2014-10-22 11:23, Corinna Vinschen wrote: > > - Drop the current working directory from the default DLL search path in > favor of Cygwin's /bin dir. I'm not so comfortable with this one. I use PATH=/my/dir/bin:/usr/bin /my/otherdir/myprog There is no DLL at all in /my/otherdir (this is the very first place for Windows to look for DLL's, and i think that this cannot change). In /my/dir/bin, there is an updated version of a library also located in /usr/bin, for example an updated cygstdc++-6.dll (from GCC 4.9.1). Does this mean that, under this change, cygstdc++-6.dll will be found in /usr/bin and not in /my/dir/bin ? In fact, this is what i can observe personnally. Also, i don't remember that the CWD has an impact on where DLL is found (apart from being in PATH, and apart from being the dir where the exe resides). For a test i have commented out in cygheap.cc the line 'wcpncpy (installation_dir, ...' (and also the next one) and the old behaviour is now back. It seems to me that this change is a regression. Could someone please argue? Regards, Denis Excoffier. -- 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] TEST RELEASE: Cygwin 1.7.33-0.1
> On 2014-10-24 13:02, Corinna Vinschen wrote:
>
> On Oct 23 20:06, Denis Excoffier wrote:
>> On 2014-10-22 11:23, Corinna Vinschen wrote:
>>>
>>> - Drop the current working directory from the default DLL search path in
>>> favor of Cygwin's /bin dir.
>> I'm not so comfortable with this one.
>>
>> I use
>> PATH=/my/dir/bin:/usr/bin /my/otherdir/myprog
>>
>> There is no DLL at all in /my/otherdir (this is the very first place
>> for Windows to look for DLL's, and i think that this cannot change).
>> In /my/dir/bin, there is an updated version of a library also
>> located in /usr/bin, for example an updated cygstdc++-6.dll (from GCC 4.9.1).
>>
>> Does this mean that, under this change, cygstdc++-6.dll will be found
>> in /usr/bin and not in /my/dir/bin ? In fact, this is what i can
>> observe personnally.
>>
>> Also, i don't remember that the CWD has an impact on where DLL is found
>> (apart
>> from being in PATH, and apart from being the dir where the exe resides).
>>
>> For a test i have commented out in cygheap.cc the line
>> 'wcpncpy (installation_dir, ...' (and also the next one)
>> and the old behaviour is now back.
>>
>> It seems to me that this change is a regression. Could someone please argue?
>
> Hmm. It's hard to do the right thing here, I guess. I can see how
> this is a regression in your scenario. OTOH, your scenario is not
> stable. The directories in $PATH are the last ones in the DLL search
> order. So, your scenario already wouldn't work if your CWD is /bin
> (or /usr/bin).
Typically, the line 'PATH=/my/dir/bin:/usr/bin /my/otherdir/myprog' is
in a Makefile, as part of some 'make check'. I don't usually build
from /usr/bin.
I was not aware that CWD was useful. IIUC, your change removes the lookup
into CWD (and replaces with a lookup to somewhere else). Who needs CWD at
the first place? These people (or specification?) will not be OK now.
>
> From Cygwin's POV {/usr}/bin is a system dir. For security reasons it
> makes sense that the system DLLs in /bin cannot be overridden, unless
> it's an installation issue which should be covered by looking into the
> application installation dir first.
Instead of adding the lookup of /usr/bin before the PATH, you could add
it afterwards? Or do you mean that my use is bad practice for security
reasons? That there might be some unexpected DLL somewhere in the PATH?
IIRC, in linux/solaris, LD_LIBRARY_PATH is not honored when you are root,
not otherwise.
>
> Having said that, moving your DLLs into the application dir is really
> not an option?
Oh yes, i use it all the time. It is the job of 'make install' to also
install the appropriate DLLs. The point here is for 'make check'.
>
> Does anybody else have a similar scenario to cover, which doesn't work
> anymore with this change?
Yes please?
Regards,
Denis Excoffier.
--
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] TEST RELEASE: Cygwin 1.7.33-0.1
2014-10-24 22:16, Christian Franke wrote:
>
> Corinna Vinschen wrote:
>>
>> Sigh.
>>
>> I don't like the idea either that this simple change breaks existing
>> scenarios. I'm inclined to revert this change.
>>
>> Christian, would you mind terribly to re-add the tweak to postfix
>> to set $PATH?
>>
>
> No problem.
>
> Another possible solution:
> Check for e.g. CYGWIN_DLLPATH environment variable before calling
> SetDllDirectory().
>
> If unset or empty, call SetDllDirectory("X:\path_to_cygwin\bin");
> else if set to ".", do nothing.
> else call SetDllDirectory(CYGWIN_DLLPATH);
>
> The above 'make check' should then work again as 'CYGWIN_DLLPATH=. make
> check'.
I can buy this. Setting 'export CYGWIN_DLLPATH := .' at the beginning of the
Makefile will
do the job.
>
> Possible enhancement: If AddDllDirectory() is available (>= Win8), accept a
> real search path in CYGWIN_DLLPATH.
Also perhaps you can use yet another subitem in the CYGWIN environment variable?
Denis Excoffier.
--
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] TEST RELEASE: Cygwin 1.7.33-0.1
On 2014-10-25 16:49, Corinna Vinschen wrote:
>
> On Oct 25 13:10, Corinna Vinschen wrote:
>> On Oct 24 23:17, Denis Excoffier wrote:
>>> 2014-10-24 22:16, Christian Franke wrote:
>>>> Another possible solution:
>>>> Check for e.g. CYGWIN_DLLPATH environment variable before calling
>>>> SetDllDirectory().
>>>>
>>>> If unset or empty, call SetDllDirectory("X:\path_to_cygwin\bin");
>>>> else if set to ".", do nothing.
>>>> else call SetDllDirectory(CYGWIN_DLLPATH);
>>>>
>>>> The above 'make check' should then work again as 'CYGWIN_DLLPATH=. make
>>>> check'.
>>> I can buy this. Setting 'export CYGWIN_DLLPATH := .' at the beginning of
>>> the Makefile will
>>> do the job.
>>>
>>>>
>>>> Possible enhancement: If AddDllDirectory() is available (>= Win8), accept
>>>> a real search path in CYGWIN_DLLPATH.
>>> Also perhaps you can use yet another subitem in the CYGWIN environment
>>> variable?
>>
>> If AddDllDirectory works without much hassle, which I have to test first,
Doesn't the "(>= Win8)" (a few lines before) prevent this scenario from working
with XP SP3?
>> why introduce CYGWIN_DLLPATH or another CYGWIN item?
>>
>> LD_LIBRARY_PATH would be the one we want then, wouldn't it?
>
> One really big problem with AddDllDirectory is this: While you can add
> multiple directories to the search path, the order in which these
> directories are added does not specify a search order. In fact, the
> order in which the paths are searched is unspecified per MSDN.
>
> In Denis example that means, if we add /usr/bin and /my/dir/bin to the
> DLL search path, Denis case works or it doesn't, and we never know when
> it will work and when it won't, and we have no way to influence this.
> Oh boy.
>
> Apart from SetDllDirectory and AddDllDirectory, what about this very
> simple solution in Cygwin:
>
> - Don't call SetDllDirectory at all, thus "." is kept in the search
> path.
>
> - In execve, when creating the Windows environment for the child process,
> check if $PATH is empty. If so, set $PATH to /bin for the child.
> Or, check if /bin is in $PATH, if not, add it.
Then you may add it at the beginning. People that would want it at the end (or
elsewhere) can insert it explicitly. Also make sure to consider /usr/bin and
/bin
as being equivalent here.
However, modifying PATH behind the scenes may be considered as an unexpected
intrusion by the user (PATH is for user consumption isn't it?). Aren't there
any legitimate scenarios where the user would omit /usr/bin from the PATH?
Is it possible to SetDllDirectory("/usr/bin") only if /usr/bin is _not_ in PATH?
This would be less intrusive.
>
> That would catch both problems, backward compatibility with Denis
> scenario, as well as the PATH setting in postfix.
This corresponds to my current patched cygwin1.dll (where i commented out 2
lines
in cygheap.cc, see previous messages), since i keep /usr/bin in PATH.
Denis Excoffier.
--
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] TEST RELEASE: Cygwin 1.7.33-0.3
On 2014-10-27 22:46, Corinna Vinschen wrote: > > Hi Cygwin friends and users, > > > I just released a 3rd TEST version of the next upcoming Cygwin release, > 1.7.33-0.3. Not found for the moment (it's okay of course), but found a new snapshot. This remembers me that for some time now, there are /usr/include/rpc/types.h and /usr/include/rpc/xdr.h which are present in the snapshots but not in releases. This is just a remark and i suppose this is ok. Regards, Denis Excoffier. -- 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] TEST RELEASE: Cygwin 1.7.33-0.4
On 2014-10-29 13:08, Corinna Vinschen wrote: > > I just released a 4th TEST version of the next upcoming Cygwin release, > 1.7.33-0.4. > > Changes compared to the former test version 1.7.33-0.3: > > - Set CYGWIN=dosfilewarning settting to OFF by default. > Well, this is OK i suppose. But i was using this feature in order to check that no cygwin process was left behind when i switch to a new cygwin1.dll (eg for a snapshot). Here is how. I use 'echo \\ /nonexistent*' in my .cshrc. This triggers the warning. That way, if some process from the previous cygwin1.dll was left somewhere in the background, the warning is not displayed and i get the (visual) indication that something is wrong (say: the new cygwin1.dll is not properly in function). Afterwards, since the warning is displayed only once, the warning is not displayed anymore, so the 'echo ...' is not a nuisance in .cshrc. The fact that the default is/was ON is important because otherwise the CYGWIN variable would have to be set somewhere (and before the 1st cygwin process). Currently i don't see how to replace this "feature". Any ideas? To be precise, the exact command that i use (in .cshrc) is echo \\ /nonexistent* |& head --lines=-6 in order to show a single line (a single line is enough for a visual indication) Regards, Denis Excoffier. -- 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
qt5 announce please
Hello, Could somebody please tell us a little bit more about the new qt5-related packages that we received recently (at least for x86)? Perhaps unrelated, i cannot compile cmake-3.1.0-rc1 any more since that. Thanks in advance. Denis Excoffier. -- 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: qt5 announce please
On 2014-11-03 23:17, Yaakov Selkowitz wrote:
>
> On 2014-11-03 16:10, Denis Excoffier wrote:
>> Could somebody please tell us a little bit more about the new qt5-related
>> packages that we received recently (at least for x86)?
>
> https://cygwin.com/ml/cygwin-xfree-announce/2014-10/msg9.html
Oh, sorry, i was not aware of this cygwin-xfree-announce list.
>
>> Perhaps unrelated, i cannot compile cmake-3.1.0-rc1 any more since that.
>
> http://sourceforge.net/p/cygwin-ports/cmake/ci/master/tree/2.8.12-gui-qt4.patch
>
> or, presumably, inherit qt5 instead of qt4 and change the boostrap argument
> to --qt-qmake=${QT5_QMAKE}.
Thanks for the hints.
Regards,
Denis Excoffier.
--
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: qt5 announce please
On 2014-11-03 23:17, Yaakov Selkowitz wrote:
>>
>> On 2014-11-03 16:10, Denis Excoffier wrote:
>
>>
>>> Perhaps unrelated, i cannot compile cmake-3.1.0-rc1 any more since that.
>>
>> http://sourceforge.net/p/cygwin-ports/cmake/ci/master/tree/2.8.12-gui-qt4.patch
>>
>> or, presumably, inherit qt5 instead of qt4 and change the boostrap argument
>> to --qt-qmake=${QT5_QMAKE}.
>
> Thanks for the hints.
Like in 2.8.12-gui-qt4.patch, i commented out "find_package(Qt5Core QUIET)" in
Tests/RunCMake/CMakeLists.txt
and also "find_package(Qt5Widgets QUIET NO_MODULE)" in Tests/CMakeLists.txt.
Only then i was able to compile
successfully. Also, i didn't touch the "find_package(Qt5Widgets QUIET)" in
Source/QtDialog/CMakeLists.txt
which does not seem to cause any harm.
Thanks,
Denis Excoffier.
--
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: Cygwin 1.7.33-1
On 2014-11-13 17:37, Corinna Vinschen wrote: > > I just released Cygwin 1.7.33-1. Just to report that 'uname -a' (and also /proc/version) shows 1.7.33-2 for this one. Denis Excoffier. -- 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: Incorrect workaround for KB 823764 in fhandler_socket.cc
On 2014-11-14 05:37, Iuliu Rus wrote: > > What is the procedure for submitting patches for cygwin? See https://cygwin.com/contrib.html Denis Excoffier. -- 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
subversion and permissions
Hello, I'm asking for advice because i don't know how to handle this. I have access to an svn repository through the "file:" protocol. The svn repository is homed on an ntfs disk, with all ACL permissions inherited from a top directory: various kinds of Administrators (not me) have many rights. A single dedicated group is allowed r/w access, and i belong to this group of course, like all my colleagues that also have access to this repository. Most of my colleagues use Windows tools (TortoiseSVN) and all is ok for them. I'd like to use Cygwin of course, and we have subversion-1.8.10 (on x86) which is in use at other places and seems ok. Indeed, 'svn checkout' and more generally all read-only activity does work perfectly on this repository. But i do encounter some problems with 'svn commit': it always fail with "Permission denied". I tried to write directly to the disk and of course it works. The issue (to my current understanding) is (details omitted): - svn internally uses a temporary file (e.g. the file "current" under the folder "db") - the file is created (in fact: truncated to empty) by Cygwin with permissions set to '---rwx---': no permissions for user (the ACL entries show no mention of any user), rwx for group (and for others we don't care) - Cygwin (chmod in fact, called by libapr) implements the '---' for user: it insists, using the Deny/Allow mechanism described in https://cygwin.com/cygwin-ug-net/ntsec.html, that the user will not be capable of reading the file, and... succeeds - indeed, the user (i.e. the svn process that created the file) cannot read it any more and terminates with permission denied (and repository is locked and must be manually "svnadmin recover'ed"). In fact, Windows users do not need to have any personal right on a file to be able to read its content: it is enough that they belong to a group that has the appropriate access. For Cygwin users, this is not the same: permissions for user and permissions for group are separate. To make things work today, i had no better idea than patching the Cygwin dll in order to temporarily disconnect the insertion of Deny rights. It works of course, but it cannot be an option for tomorrow. Is there any way to handle this problem cleanly, preferably without changing any permissions on the repository? I tried to mount the disk noacl, the problem remains exactly the same. Thank you for your suggestions, Regards, Denis Excoffier. -- 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: subversion and permissions
On 2014-11-28 03:32, Andrey Repin wrote: > > Look, this happens, when you are not reading documentation... > Or, if you're in a hurry, the 'noacl' mount flag is what you are looking for. You are totally right. The part of documentation that i have missed is in https://cygwin.com/cygwin-ug-net/using.html#mount-table : The cygdrive prefix may be changed in the fstab file as outlined above. Please note that you must not use the cygdrive prefix for any other mount point. For instance this: none /cygdrive cygdrive binary 0 0 D: /cygdrive/d somefs text 0 0 will not make file access using the /mnt/d path prefix suddenly using textmode. If you want to mount any drive explicitly in another mode than the cygdrive prefix, use a distinct path prefix: none /cygdrive cygdrive binary 0 0 D: /mnt/d somefs text 0 0 Thank you and sorry for the noise. Denis Excoffier. -- 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] TEST RELEASE: Cygwin 1.7.34-005
On 2015-01-20 17:42, Corinna Vinschen wrote: > > I released another TEST version of the next upcoming Cygwin release. > The version number is 1.7.34-005. I compiled this one successfully on CYGWIN_NT-6.1-WOW64 (W7 with Cygwin 32bits), but on CYGWIN_NT-5.1 (XP) i get: make: *** INTERNAL: readdir: No such file or directory. Stop. More precisely it fails when inside the ./cygserver folder: % make -d |& tail Prerequisite '/tmp/lcl/tmp/cygwin/src/winsup/cygserver/transport.h' is older than target 'pwdgrp.o'. Prerequisite '/tmp/lcl/tmp/cygwin/src/winsup//cygwin/cygserver_pwdgrp.h' is older than target 'pwdgrp.o'. Prerequisite '/tmp/lcl/tmp/cygwin/src/winsup//cygwin/cygserver.h' is older than target 'pwdgrp.o'. No need to remake target 'pwdgrp.o'. Considering target file '/tmp/lcl/tmp/cygwin/obj/i686-pc-cygwin/winsup/cygwin/version.o'. Looking for an implicit rule for '/tmp/lcl/tmp/cygwin/obj/i686-pc-cygwin/winsup/cygwin/version.o'. Trying pattern rule with stem 'version'. Trying implicit prerequisite '/version.cc'. make: *** INTERNAL: readdir: No such file or directory. Stop. make: /tmp/lcl/tmp/cygwin/obj/i686-pc-cygwin/winsup/cygwin/version.o: Field 'stem' not cached: version % Like advertised, it seems to have something to do with the internals of the make utility, therefore i restarted the compilation anew with 'make --no-builtin-rules' (or '-r') with the same result. In the cygserver folder, i replaced CYGWIN_OBJS:=$(cygwin_build)/version.o by CYGWIN_OBJS:= (since version.o is already built anyway) with also the same result. No further idea for the moment. The last snapshot (20150119) has the same problem (again, only for XP). Older snapshots i don't know, but 20150113 was OK. I cannot formally exclude antivirus and all such kinds of things. Probably the bug-make mailing list would be more appropriate. Hope this helps though. Regards, Denis Excoffier. -- 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] TEST RELEASE: Cygwin 1.7.34-005
On 2015-01-22 10:14, Corinna Vinschen wrote: > > This doesn't look like an actual Cygwin problem. There's no difference > between XP and W7 inside of Cygwin which would explain this behaviour. Yes, sure. In any case the problem has moved into another field: % /usr/bin/ls / /usr/bin/ls: reading directory /: No such file or directory (regular ls output follows) % This explains probably the 'INTERNAL: readdir: No such file or directory' behaviour. In addition, i'm now unable to compile the 20150113 snapshot any more although it was ok at that time. Now I have to check whether somebody could have applied some antivirus update, software update or anything else on my PC. Denis Excoffier. -- 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] TEST RELEASE: Cygwin 1.7.34-005
On 2015-01-22 23:07, Denis Excoffier wrote: > > % /usr/bin/ls / > /usr/bin/ls: reading directory /: No such file or directory > (regular ls output follows) > % > I reinstalled cygwin completely. The problem is now vanished. No idea what caused the problem. Denis Excoffier. -- 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] TEST RELEASE: Cygwin 1.7.34-005
On 2015-01-24 17:45, Denis Excoffier wrote:
>
> On 2015-01-22 23:07, Denis Excoffier wrote:
>>
>> % /usr/bin/ls /
>> /usr/bin/ls: reading directory /: No such file or directory
>> (regular ls output follows)
>> %
>>
> I reinstalled cygwin completely.
> The problem is now vanished.
>
> No idea what caused the problem.
Now i know: in /etc/fstab i have the line:
X:/some/svnrepository /svnX ntfs cygexec,noacl
which works well when X: is there, but which produces
the above message when i'm at home.
End of the story? Not really:
1) perhaps the /usr/bin/ls message would deserve some improvement,
by naming the failing folder (/svnX)
2) why is the build of cygserver impacted by something that takes
place at the root directory (see "Trying implicit prerequisite
'/version.cc'." in
https://cygwin.com/ml/cygwin/2015-01/msg00294.html)?
For item 2: Bingo! Perhaps unexpectedly, $(cygwin_source) is unknown within
cygwin sources...
Please apply the following:
diff -uNr cygwin-snapshot-20150122-1.vanilla/winsup/cygserver/Makefile.in
cygwin-snapshot-20150122-1.patched/winsup/cygserver/Makefile.in
--- cygwin-snapshot-20150122-1.vanilla/winsup/cygserver/Makefile.in
2014-07-24 15:21:47.0 +0200
+++ cygwin-snapshot-20150122-1.patched/winsup/cygserver/Makefile.in
2015-01-28 10:36:17.0 +0100
@@ -73,10 +73,10 @@
cygserver.exe: $(CYGWIN_LIB) $(OBJS) $(CYGWIN_OBJS)
$(CXX) -o $@ ${wordlist 2,999,$^} -static -static-libgcc
-B$(cygwin_build) -lntdll
-$(cygwin_build)/%.o: $(cygwin_source)/%.cc
+$(cygwin_build)/%.o: $(cygwin_build)/%.cc
@$(MAKE) -C $(@D) $(@F)
-$(cygwin_build)/%.o: $(cygwin_source)/%.c
+$(cygwin_build)/%.o: $(cygwin_build)/%.c
@$(MAKE) -C $(@D) $(@F)
Makefile: Makefile.in configure
Regards,
Denis Excoffier.
--
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] TEST RELEASE: Cygwin 1.7.35-0.1
On 2015-02-12 21:23, Corinna Vinschen wrote: > > Hi Cygwin friends and users, > > > I released a very early TEST version of the next upcoming Cygwin > release. The version number is 1.7.35-0.1. > ... > > If you're not familiar with the new account information handling > introduced in Cygwin 1.7.34, I suggest to read the new documentation > at https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping > > > The essential changes in this test release are: > > - The default settings for db_home, db_shell, and db_gecos in case > there's no /etc/nsswitch.conf file, or if they are not mentioned > in /etc/nsswitch.conf, are now set to just the fallback, which is > >db_home: /home/%U >db_shell: /bin/bash >db_gecos: > I tried (according to the new documentation): db_home: /%H/%U/cygdir and that was fine but %H was replaced by the /cygdrive/C/Document and Settings/ prefix, although i was expecting the /cygdrive/C/Home/ prefix instead. I have to confess that i used here the nearly-to-be-obsoleted XP SP3. But i also use W7 sometimes, and it would be great if i could have "db_home: /%H/%U/cygdir" in both of them (yes my username has to appear twice): no /etc/passwd any more. Regards, Denis Excoffier. -- 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] TEST RELEASE: Cygwin 1.7.35-0.1
On 2015-02-13 22:04, Warren Young wrote: > >> On Feb 13, 2015, at 11:30 AM, Denis Excoffier >> wrote: >> >> I tried (according to the new documentation): >> >> db_home: /%H/%U/cygdir >> >> and that was fine but %H was replaced by the >> /cygdrive/C/Document and Settings/ prefix > > I don’t think you should use %H when that directory might contain spaces. > It’s likely to cause many problems. You misunderstand. I don't need this stupid 'Document and Settings' thing. I need %H to represent my home dir, that means /cygdrive/d/Home/myuser1 on this XP P3 (a corporate one) and /cygdrive/c/Users/myuser2 on this W7 (another corporate). That way, using %H/%U/cygdir under both architectures would generate the right thing. But currently, on XP SP3, the %H is replaced by '/cygdrive/d/Document and Settings/myuser1' which i'm pretty close to consider as a bug. Should be '/cygdrive/d/Home/myuser1' i suppose. > > I may be misunderstanding your desire. If you actually want Cygwin home > directories under c:\Documents and Settings, you can combine nsswitch.conf > settings with a custom mount point in fstab to avoid the need for spaces in > $HOME: > >C:/Documents\040and\040Settings /home ntfs binary 0 0 Good idea (a symlink would also do the job wouldn'it?) but i really don't need this. I don't like spaces in filenames either: they don't fit nicely in makefiles. Regards, Denis Excoffier. -- 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] TEST RELEASE: Cygwin 1.7.35-0.1
On 2015-02-13 22:30, Denis Excoffier wrote: > > On 2015-02-13 22:04, Warren Young wrote: >> >>> On Feb 13, 2015, at 11:30 AM, Denis Excoffier >>> wrote: >>> >>> I tried (according to the new documentation): >>> >>> db_home: /%H/%U/cygdir >>> >>> and that was fine but %H was replaced by the >>> /cygdrive/C/Document and Settings/ prefix >> >> I don’t think you should use %H when that directory might contain spaces. >> It’s likely to cause many problems. > > You misunderstand. I don't need this stupid 'Document and Settings' thing. I > need %H to represent my home dir, that means > /cygdrive/d/Home/myuser1 on this XP P3 (a corporate one) and > /cygdrive/c/Users/myuser2 on this W7 (another corporate). > That way, using %H/%U/cygdir under both architectures would generate the > right thing. > > But currently, on XP SP3, the %H is replaced by '/cygdrive/d/Document and > Settings/myuser1' which i'm pretty > close to consider as a bug. Should be '/cygdrive/d/Home/myuser1' i suppose. Oops. I'm wrong. Until this morning i really thought that XP comes with two "personal places" for each user: - C:/Home/user for the personal files of the user (that can be called the home directory) - C:/Document and Settings/user for the internal Windows files (Program Files etc.) not for normal user consumption This, because our IT people are keen enough to provide us a "secondary" place where to put our personal files. I imagine they had too many complaints about spaces in directory names. Sorry for the noise. Denis Excoffier. -- 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
minor improvement for base-cygwin
Here is a minor improvement for base-cygwin: diff -uNr etc/postinstall/000-cygwin-post-install.sh etc-patched/postinstall/000-cygwin-post-install.sh --- etc/postinstall/000-cygwin-post-install.sh 2015-02-04 17:45:52.0 +0100 +++ etc-patched/postinstall/000-cygwin-post-install.sh 2015-02-24 20:42:45.0 +0100 @@ -74,6 +74,7 @@ # Defaults: # passwd: files db # group:files db +# db_enum: cache builtin # db_home: cygwin desc # db_shell: cygwin desc # db_gecos: cygwin desc Denis Excoffier. -- 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] TEST RELEASE: Cygwin 1.7.35-0.3
On 2015-02-26 17:03, Corinna Vinschen wrote: > > On Feb 20 09:25, Achim Gratz wrote: >> Another thing I noticed is that pasting into an SSH connection often >> leaves the last few characters off and you need to hit another key to >> get them displayed. Not sure if this is related, but I seem to remember >> that this had been reported before and may be a regression. > > This should be fixed in CVS. In the pty function reading the input and > doing all the canonical/non-canonical mode stuff, evaluating special > characters etc, a condition was wrong which lead to keeping bytes in > the buffer which should have been read. > Perhaps this will also solve an issue that i still have not reported, namely under /usr/bin/script, i have to hit 4 times the Return key for the commandline to accept my command. The other characters no problem, only the Return key. My shell is tcsh under XP. The typescript file contains Control-M twice (followed by a regular \012), as expected. Regards, Denis Excoffier. -- 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] (last?) TEST RELEASE: Cygwin 1.7.35-0.5
On 2015-02-27 18:52, Corinna Vinschen wrote: > > I released another TEST version of the next upcoming Cygwin release. > I have noticed that the behavior of /usr/bin/script is not better than previously (probably the change resides near https://cygwin.com/ml/cygwin-cvs/2015-q1/msg00094.html). For at least several weeks, the behavior was ok, except for the Return key, which had to be hit several times to take effect. But the other characters were ok. Now (after 2015-02-26), only every fourth character that i type is flushed to the command line, Return key included. For example, suppose that my command is "abcdefgh": only after i hit the 'd' key is "abcd" displayed, and only after i hit the 'h' key the "efgh" is displayed (the command line reads "abcdefgh"); now i have to hit four times the return key to "enter" the command. Previously, the fourth-character-delay was probably already there, but only for the Return key. Hope this helps. Regards, Denis Excoffier. -- 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
speedup in AD access, thanks
Hi, Playing with mkgroup and mkpasswd like others, i also noticed some great improvement in performance: now less than 5min for 404653 entries (mkpasswd -d) and less that 1min for 127048 entries (mkgroup -d). Before it was nearly 1 hour for each. Playing also with /etc/group, i happened to enter an empty group (i.e. line begins with colon) and e.g. ls -al fails miserably in this case (and segfault seems to lie in cygwin1.dll). Regards, Denis Excoffier. -- 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
bad interaction with /usr/bin/make
Hi, This is a standard makefile, except that hello.c is taken from a special directory: % cat Makefile all : hello hello : hello.o gcc -o $@ $+ hello.o : /usr/mydata/hello.c gcc -o $@ -c $< clean : -rm -f hello hello.exe hello.o % The file hello.c contains exactly what you expect that it should contain and the ./hello runs OK. Now, suppose that you mount (through /etc/fstab) some drive under some subfolder of /usr/mydata, eg R:/svnRepository /usr/mydata/svn ntfs cygexec,noacl You can try the Makefile, it still works (as expected). Now you come home and the R: drive does not exist any more. Believe it or not (but you can try), the Makefile does not work any more and produces: make: *** INTERNAL: readdir: No such file or directory. Stop. You can observe that the /usr/mydata/hello.c still exists, unchanged, and that the mount has nothing to do with /usr/mydata, only with /usr/mydata/svn, which is unknown in the Makefile. Do you think that Cygwin has something to do with this or is it exclusively /usr/bin/make's business? Regards, Denis Excoffier. -- 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
xlaunch small glitch
Hi,
In the last xlaunch package, the etc/postinstall/xlaunch.sh reads:
% cat /etc/postinstall/xlaunch.sh.done
# add a start menu shortcut
case $(uname -s) in *-WOW64) wow64=" (32-bit)" ;; esac
/usr/bin/mkdir -p "$(/usr/bin/cygpath $CYGWINFORALL -P)/Cygwin-X${wow64}"
/usr/bin/mkshortcut $CYGWINFORALL -P -i /usr/bin/xlaunch.exe -n
"Cygwin-X${wow64}/XLaunch" -a "/usr/bin/bash.exe -l -c /usr/bin/xlaunch.exe"
/usr/bin/run.exe
# add file association for opening and editing .xlaunch files
/usr/share/xlaunch/setupreg.sh add
%
The "WOW64" on second line should be changed into "WOW*" (or equivalent) since
now the W7 32bits are now called "CYGWIN_NT-6.1-WOW".
Regards,
Denis Excoffier.
--
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 hangs up if several keys are typed during outputting a lot of texts.
On 2015-02-28 06:40, Takashi Yano wrote: > > Package: cygwin > Version: 1.7.34-6 > > Cygwin often hangs up if several keys are input during a lot of text outputs. > > To reproduce this problem: > 1) Start a new cygwin session on mintty. > 2) Execute > yes > or > od /dev/urandom > 3) Hit 'a' key several times during text outputs. > > If echo is disabled like: > stty -echo; yes > > the problem does not occur. > > I concur. The same occurs under xterm and 1.7.35-0.5 (under NT). You can pipe your yes/od command into 'head -1' and the same applies (as long as you type the additional characters before the end of course). In fact, Cygwin does not hang, only the xterm window hangs. And, the same: with 'stty -echo' the problem does not occur. I'll add that this is not new (occurred for me at least for the last few months, even perhaps years). I'm happy that Takashi found: - a fully reproducible case - that the problem vanishes with stty -echo (that could perhaps mean a quick resolution...) Regards, Denis Excoffier. -- 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] (last?) TEST RELEASE: Cygwin 1.7.35-0.5
On 2015-02-28 13:13, Corinna Vinschen wrote: > > On Feb 28 00:23, Denis Excoffier wrote: >> On 2015-02-27 18:52, Corinna Vinschen wrote: >>> >>> I released another TEST version of the next upcoming Cygwin release. >>> >> I have noticed that the behavior of /usr/bin/script is not better than >> previously (probably the change resides near >> https://cygwin.com/ml/cygwin-cvs/2015-q1/msg00094.html). >> >> For at least several weeks, the behavior was ok, except for the >> Return key, which had to be hit several times to take effect. But the >> other characters were ok. >> >> Now (after 2015-02-26), only every fourth character that i type >> is flushed to the command line, Return key included. For example, >> suppose that my command is "abcdefgh": only after i hit the 'd' key >> is "abcd" displayed, and only after i hit the 'h' key the >> "efgh" is displayed (the command line reads "abcdefgh"); now >> i have to hit four times the return key to "enter" the command. >> >> Previously, the fourth-character-delay was probably already there, >> but only for the Return key. > > I can't reproduce this. I started script, script starts my shell, and > then I can type and I see every character I type immediately, including > the ENTER key. I tried with SHELL set to /bin/tcsh as well as with > /bin/bash. > Oops, forgot to mention: it is under xterm only. Under cmd.exe or under mintty, all is correct. Denis Excoffier. -- 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: speedup in AD access, thanks
On 2015-02-28 13:16, Corinna Vinschen wrote: > > On Feb 28 00:51, Denis Excoffier wrote: >> Hi, >> >> Playing with mkgroup and mkpasswd like others, i also >> noticed some great improvement in performance: >> now less than 5min for 404653 entries (mkpasswd -d) >> and less that 1min for 127048 entries (mkgroup -d). >> Before it was nearly 1 hour for each. >> >> Playing also with /etc/group, i happened to enter >> an empty group (i.e. line begins with colon) and >> e.g. ls -al fails miserably in this case (and segfault >> seems to lie in cygwin1.dll). > > I'm not overly sympathetic with screwed up /etc/passwd or /etc/group > files. In this case it was a missing error check. I applied a fix > and the next version won't crash in this situation. Thank you. In fact i need /etc/group since i want to display the same group _name_ when i'm AD-connected and when i am not. Until now i was happy with "Domain Users". From now on i'll use "-". Denis Excoffier. -- 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 svn vs. TortoiseSVN?
On 2015-03-18 19:45, David Stacey wrote: > > I have a PC with both Cygwin and TortoiseSVN. When I try to commit through > Cygwin svn, I get the following (slightly redacted): > > Committed revision n. > svn: E20: Commit succeeded, but other errors follow: > svn: E155009: Error bumping revisions post-commit (details follow): > svn: E155009: Failed to run the WC DB work queue associated with > '/cygdrive/D/xxx/yyy', work item 528 (file-commit aaa/bbb.c) > svn: E13: Can't open file '/cygdrive/D/xxx/yyy/.svn/tmp/svn-sckggY': > Permission denied Just in case: mount the appropriate part of your D disk with the 'noacl' option, ie add something like D:/Wherever/Is/Your/SVNRepository /svnR ntfs cygexec,noacl at the end of your /etc/fstab, and use file:///svnR for your repo. See also for https://cygwin.com/cygwin-ug-net/using.html#mount-table, especially the word "suddenly". Hope this helps. Denis Excoffier. -- 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
Under /bin/script, characters get printed in four-character chunks
On 2015-02-28 16:30, Corinna Vinschen wrote:
>
> On Feb 28 15:19, Denis Excoffier wrote:
>> On 2015-02-28 13:13, Corinna Vinschen wrote:
>>>
>>> On Feb 28 00:23, Denis Excoffier wrote:
>>>> On 2015-02-27 18:52, Corinna Vinschen wrote:
>>>>>
>>>>> I released another TEST version of the next upcoming Cygwin release.
>>>>>
>>>> I have noticed that the behavior of /usr/bin/script is not better than
>>>> previously (probably the change resides near
>>>> https://cygwin.com/ml/cygwin-cvs/2015-q1/msg00094.html).
>>>>
>>>> For at least several weeks, the behavior was ok, except for the
>>>> Return key, which had to be hit several times to take effect. But the
>>>> other characters were ok.
>>>>
>>>> Now (after 2015-02-26), only every fourth character that i type
>>>> is flushed to the command line, Return key included. For example,
>>>> suppose that my command is "abcdefgh": only after i hit the 'd' key
>>>> is "abcd" displayed, and only after i hit the 'h' key the
>>>> "efgh" is displayed (the command line reads "abcdefgh"); now
>>>> i have to hit four times the return key to "enter" the command.
>>>>
>>>> Previously, the fourth-character-delay was probably already there,
>>>> but only for the Return key.
>>>
>>> I can't reproduce this. I started script, script starts my shell, and
>>> then I can type and I see every character I type immediately, including
>>> the ENTER key. I tried with SHELL set to /bin/tcsh as well as with
>>> /bin/bash.
>>>
>> Oops, forgot to mention: it is under xterm only. Under cmd.exe or under
>> mintty, all is correct.
>
> Since when do you see this problem?
>
> I can not reproduce this in mintty, nor in a Cygwin xterm started on a
> remote X server running under Linux. I can reproduce this with a local
> xterm started via startxwin. But, and that's the problem, I can
> reproduce it with the current 1.7.35-0.5 test release, with 1.7.34, and
> last but not least also with a debug version of the Cygwin DLL in which I
> backed out all PTY-related changes since last November.
>
> I'm not sure this is a giveaway, but from that it seems this problem
> is not directly related to a Cygwin change in the last months.
>
> So, jturney and I are wondering when exactly you encountered this problem
> for the first time. Did it coincide with a certain Cygwin release,
> or a certain X server? Or new X libs, perhaps?
>
> Anything you can provide to narrow down the potential culprit would be
> helpful.
>
Well. Here is some more inputs.
This is connected with the "min" option of stty. When this occurs,
'stty -a' says '4' for min. If i change into 'stty min 5' the characters
come by chunks of 5.
I had a look into the sources of xterm, xinit, coreutils, tcsh and cygwin and
i definitely don't understand where the 4 comes from. In any case, 4 should not
be
the problem, because 'stty min 4' is perfectly legitimate.
The doc of stty says that 'min' (and 'time') are used in case of '-icanon'.
However, i found in fhandler_tty.cc that it seems not to be always the case.
After i applied the following patch:
diff -uNr cygwin-snapshot-20150317-1.original/winsup/cygwin/fhandler_tty.cc
cygwin-snapshot-20150317-1.patched/winsup/cygwin/fhandler_tty.cc
--- cygwin-snapshot-20150317-1.original/winsup/cygwin/fhandler_tty.cc
2015-03-17 11:42:16.0 +0100
+++ cygwin-snapshot-20150317-1.patched/winsup/cygwin/fhandler_tty.cc
2015-03-24 19:32:42.0 +0100
@@ -715,7 +715,7 @@
if (is_nonblocking () || !ptr) /* Indicating tcflush(). */
time_to_wait = 0;
- else if ((get_ttyp ()->ti.c_lflag & ICANON))
+ else if (!(get_ttyp ()->ti.c_lflag & ICANON))
time_to_wait = INFINITE;
else
{
and the problem was gone. Let's try an explanation:
the problem is present since "the beginning", at least
since 2000-02-17, see
https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/fhandler_tty.cc;hb=1fd5e000ace55b323124c7e556a7a864b972a5c4,
and recent (2014-11-13) changes in fhandler_tty.cc made it to appear.
Perhaps i'm also completely wrong.
Hoping this will help,
Regards,
Denis Excoffier.
--
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: X server sets VMIN? (was Re: Under /bin/script, characters get printed in four-character chunks)
On 2015-03-24 20:53, Corinna Vinschen wrote:
>
> On Mar 24 19:59, Denis Excoffier wrote:
>> On 2015-02-28 16:30, Corinna Vinschen wrote:
>>> I can not reproduce this in mintty, nor in a Cygwin xterm started on a
>>> remote X server running under Linux. I can reproduce this with a local
>>> xterm started via startxwin. But, and that's the problem, I can
>>> reproduce it with the current 1.7.35-0.5 test release, with 1.7.34, and
>>> last but not least also with a debug version of the Cygwin DLL in which I
>>> backed out all PTY-related changes since last November.
>>>
>>> I'm not sure this is a giveaway, but from that it seems this problem
>>> is not directly related to a Cygwin change in the last months.
>>>
>>> So, jturney and I are wondering when exactly you encountered this problem
>>> for the first time. Did it coincide with a certain Cygwin release,
>>> or a certain X server? Or new X libs, perhaps?
>>>
>>> Anything you can provide to narrow down the potential culprit would be
>>> helpful.
>>>
>> Well. Here is some more inputs.
>>
>> This is connected with the "min" option of stty. When this occurs,
>> 'stty -a' says '4' for min. If i change into 'stty min 5' the characters
>> come by chunks of 5.
>>
>> I had a look into the sources of xterm, xinit, coreutils, tcsh and cygwin and
>> i definitely don't understand where the 4 comes from. In any case, 4 should
>> not be
>> the problem, because 'stty min 4' is perfectly legitimate.
>>
>> The doc of stty says that 'min' (and 'time') are used in case of '-icanon'.
>> However, i found in fhandler_tty.cc that it seems not to be always the case.
>> After i applied the following patch:
>>
>> diff -uNr cygwin-snapshot-20150317-1.original/winsup/cygwin/fhandler_tty.cc
>> cygwin-snapshot-20150317-1.patched/winsup/cygwin/fhandler_tty.cc
>> --- cygwin-snapshot-20150317-1.original/winsup/cygwin/fhandler_tty.cc
>> 2015-03-17 11:42:16.0 +0100
>> +++ cygwin-snapshot-20150317-1.patched/winsup/cygwin/fhandler_tty.cc
>> 2015-03-24 19:32:42.0 +0100
>> @@ -715,7 +715,7 @@
>>
>> if (is_nonblocking () || !ptr) /* Indicating tcflush(). */
>> time_to_wait = 0;
>> - else if ((get_ttyp ()->ti.c_lflag & ICANON))
>> + else if (!(get_ttyp ()->ti.c_lflag & ICANON))
>
> No, this is wrong. You're switching the code for icanon with the
> code for -icanon. -icanon in stty means ICANON is switched off.
>
> I just gave it another try and the behaviour is perfectly valid.
>
> The real problem is that "something" is setting VMIN to 4. And that's
> somehow inside the X server, if I'm not completely wrong:
>
> - If you start an xterm from mintty like this:
>
>xterm -display :0
>
> and then call `stty -a' in it, you'll see that min is 1, and then
> script will behave as desired.
>
> - However, if you start xterm from the X server tray icon and then
> call `stty -a' in it, min is set to 4 and script will misbehave.
> If you call `stty min 1' before calling script, script will work
> as expected again.
>
> So, why does the X server (or whatever controls starting applications
> from the X server tray icon) set VMIN to 4?
>
It seems that this has something to do with tcsh (and not with XWin).
If you arrange your environment in order that the xterm launches /bin/bash
(instead of tcsh), you get min=0 under 'stty -a' and /bin/script behaves
as expected. If afterwards, in such an xterm, you run '/bin/csh -f', you get
min=4.
Consider the following:
diff -uNr tcsh-6.18.01-original/ed.init.c tcsh-6.18.01-patched/ed.init.c
--- tcsh-6.18.01-original/ed.init.c 2006-08-24 22:56:08.0 +0200
+++ tcsh-6.18.01-patched/ed.init.c 2015-03-25 15:56:33.0 +0100
@@ -65,7 +65,7 @@
(uc)CDSWTCH, (uc)CERASE2, (uc)CSTART, (uc)CSTOP,
(uc)CWERASE,(uc)CSUSP, (uc)CDSUSP, (uc)CREPRINT,
(uc)CDISCARD, (uc)CLNEXT, (uc)CSTATUS, (uc)CPAGE,
- (uc)CPGOFF, (uc)CKILL2, (uc)CBRK, (uc)CMIN,
+ (uc)CPGOFF, (uc)CKILL2, (uc)CBRK, (uc)1,
(uc)CTIME
},
{
In the original code, CMIN is set to CEOF and CEOF is set to Control-D, hence
min=4. With the patch above, all seems to go well. But this does not
explain why the min=4 is not permanent.
Regards,
Denis Excoffier.
--
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] TEST RELEASE: Cygwin 2.0.0-5
On 2015-04-16 à 18:43, Corinna Vinschen wrote: > On Apr 16 18:21, Corinna Vinschen wrote: >> On Apr 16 08:17, Jim Reisert AD1C wrote: >>> I am unable to start Cywin/X X-server 1.17.1 with this version. >>> Previous releases of 2.0.0.x were OK. I had to revert to 1.7.35-1 for >>> the time being. >>> >>> Other than updating to 2.0.0.5, I also installed the April 2015 "Patch >>> Tuesday" updates from Microsoft. I don't know if the two are related. >>> Windows 7 Home Premium, 64-bit >>> >>> Exception: STATUS_ACCESS_VIOLATION at eip=77C50F8A >>> eax= ebx=612D67B0 ecx=1000 edx=612D2648 esi= >>> edi=0028C790 >>> ebp=0028C608 esp=0028C604 program=C:\Cygwin\bin\XWin.exe, pid 1660, thread >>> main >>> cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B >>> Stack trace: >>> Frame Function Args >>> 0028C608 77C50F8A (, 612D2648, , 612D67B0) >>> 0028C738 610CDA1F (43FF, , , 80012428) > > On second thought, if I can trust the args output, that would be an > fchmod(0,0). If there's no uid or gid 0, which there isn't unless you > explicitely created them in the passwd/group files, the uid and gid have > no SID connected to. This may be the culprit here. > >> I could add an extra check which refuses to change permissions if >> the account's SID can't be found, but since this occurs very deep >> in the call stack, the error message might be pretty vapid. >> >> Alternatively I just let this slip through and you might wonder >> why the group hasn't changed in this case. > > I added a change to this effect, but it occuurs to me that this may > be really just a missing test if the uid and gid values are backed by > a real Windows account. It seems better to return EPERM here. > I applied the patch indicated (see in https://cygwin.com/ml/cygwin-cvs/2015-q2/msg00033.html) and X11 now works back again. Thank you 1000 times. Regards, Denis Excoffier. -- 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
cannot build cygwin-2.0.2 because of net.cc (or because of some header.h)
Hello,
In order to successfully build cygwin-2.0.2-1 (for x86, both XP and W7) i had
to apply
the following patch (below). No such problem with cygwin-2.0.1-1.
Regards,
Denis Excoffier
diff -uNr newlib-cygwin-o/winsup/cygwin/net.cc
newlib-cygwin-p/winsup/cygwin/net.cc
--- newlib-cygwin-o/winsup/cygwin/net.cc2015-05-08 23:51:08.0
+0200
+++ newlib-cygwin-p/winsup/cygwin/net.cc2015-05-11 10:12:57.816299800
+0200
@@ -2444,7 +2444,7 @@
return -1;
}
-extern "C" unsigned
+extern "C" NET_IFINDEX
if_nametoindex (const char *name)
{
PIP_ADAPTER_ADDRESSES pa0 = NULL, pap;
@@ -2478,7 +2478,7 @@
}
extern "C" char *
-if_indextoname (unsigned ifindex, char *ifname)
+if_indextoname (NET_IFINDEX ifindex, char *ifname)
{
PIP_ADAPTER_ADDRESSES pa0 = NULL, pap;
char *name = NULL;
--
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: tcsh-6.18.00-1
On Mon, Jan 16, 2012 at 12:20:58PM +0100, Corinna Vinschen wrote: >> I've updated the tcsh package to 6.18.00-1. After installation of this package, i discovered that the symlink /usr/bin/csh -> /usr/bin/tcsh has gone. I don't really know how it happened. Just it case it could be postinstall misbehavior? Regards, Denis Excoffier. -- 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: tcsh-6.18.00-1
On Wed, Jan 18, 2012 at 08:59:16AM +0100, Denis Excoffier wrote: >> On Mon, Jan 16, 2012 at 12:20:58PM +0100, Corinna Vinschen wrote: >> >> I've updated the tcsh package to 6.18.00-1. >> After installation of this package, i discovered that >> the symlink /usr/bin/csh -> /usr/bin/tcsh >> has gone. >> I don't really know how it happened. Just it case it could be >> postinstall misbehavior? Sure. There is no /etc/postinstall folder in the new tcsh-6.18 package. I don't understand why nobody complains. Is /bin/csh no longer used these days? Regards, Denis Excoffier. -- 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: src/winsup cygwin/release/1.7.10 doc/ChangeLog ...
On 2012-01-29 10:41, corinna wrote: > CVSROOT: /cvs/src > Module name: src > Changes by: corinna at sourceware.org 2012-01-29 09:41:06 > > Modified files: > winsup/cygwin/release: 1.7.10 > winsup/doc : ChangeLog new-features.sgml > winsup/utils : ChangeLog Makefile.in utils.sgml > Added files: > winsup/utils : tzset.c > > Log message: > * Makefile.in (CYGWIN_BINS): Add tzset. > * tzset.c: New tool, new file. > * utils.sgml (tzset): New section. > > * new-features.sgml (ov-new1.7.10): Add tzset. > > * release/1.7.10: Add tzset. Shouldn't it be tzget instead of tzset? Regards. Denis Excoffier. -- 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 User's Guide, typos
Hello, Reading the Cygwin User's Guide, i discovered a few typos (or similar) that could be corrected before 1.7.10. Search for the following: heirarchial set.i portablilty specificially existance you can invoking posix=1,-acl(hyphen should be removed) (mount option posix=0. (missing right parenthesis) (mount option binary, caseinsensitive (missing hyphen) casesensitivity relevent equalivant `All Users' (back quote) `Desktop' `Profiles' `My Documents' sufficent 0xhex cygwin DLL (capital C) in 2.1.2: The Default Text File Type... (no longer up to date) Regards, Denis Excoffier. -- 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 User's Guide, typos
On 2012-02-04 12:40, Corinna Vinschen wrote: > On Feb 4 10:04, Denis Excoffier wrote: >> Hello, >> >> Reading the Cygwin User's Guide, i discovered a few typos (or similar) that >> could be corrected before 1.7.10. >> Search for the following: >> posix=1,-acl(hyphen should be removed) > > I can't find this one. There is only one such expressions, and it > doesn't contain a hyphen: > > posix=1,acl My printed PDF shows an hyphen at the very end of the line. Could be added by the PDF generator. >> `All Users' (back quote) >> `Desktop' >> `Profiles' >> `My Documents' > > These are quotes from the output of the cygpath command. I thought that since the change of the GNU coding standards, the back quotes had been replaced with apostrophes? > I fixed the rest. It remains now: hirarchial portabilty Denis Excoffier. -- 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: cygwin-1.7.10-1
On Sun, Feb 05, 2012 at 05:29:27PM +0100, Corinna Vinschen wrote: >> >> I just released 1.7.10-1. Fine. After all these snapshots, i've still 1.7.9-1 officially installed. So setup.exe uninstalls 1.7.9-1, therefore removes /usr/include/process.h And setup.exe then installs 1.7.10-1, therefore installs /usr/include/cygwin/process.h (as for every snapshot). Now, compilation of GCC 4.7.0 (snapshot here also) is broken due to absence of /usr/include/process.h. It's a pity that the Cygwin snapshot "system", while being fairly able to test installation of new Cygwin releases, cannot test at the same time the disinstallation of the associated previous releases. Regards, Denis Excoffier. -- 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: cygwin-1.7.10-1
On Tue, Feb 07, 2012 at 03:25:20PM +0100, Corinna Vinschen wrote: >> On Feb 7 15:09, Denis Excoffier wrote: >> > On Sun, Feb 05, 2012 at 05:29:27PM +0100, Corinna Vinschen wrote: >> So, here are two questions: >> >> - Since you *knew* that the process.h header had moved for a month >> (after all, it is "as for every snapshot"), why didn't you say a single >> word that this may result in a problem with building gcc? I didn't know because /usr/include/process.h was still there. Only a "tar tvf" told me this today. Perhaps we should do: rm `tar tf ` # you got the idea before tar xf # here also at any cygwin package switch? Or at least compare the respective results of "tar tf". What do you think? >> >> - Why is that such a big problem? Changing process.h to cygwin/process.h >> should work, right? Oh yes, sure. When you have the necessary pieces it's rather easy. For the record, also perl-5.14.2 seems broken. Denis Excoffier. -- 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.10-1 fork - address space needed by ... already in use
On Tue, Feb 07, 2012 at 07:00:25AM -0800, Scott M. Ballew wrote: >> >> I've got a Windows XP SP3 (32-bit) system that I just upgraded from Cygwin >> 1.5 to Cygwin 1.7 as a clean install (deinstalled all old Cygwin, scrubbed >> the registry, cleared environment variables, etc.) Mostly, it seems to work, >> but I've got a shell script that runs several rsync's for me that does not >> work right. Some of the rsync's run correctly, and others give me: >> >> hostname1: updating host hostname1 >> 3 [main] rsync 3112 child_info_fork::abort: address space needed by >> 'cygiconv-2.dll' (0x674C) is already occupied >> 3 [main] rsync 3112 child_info_fork::abort: address space needed by >> 'cygiconv-2.dll' (0x674C) is already occupied >> rsync: fork: Resource temporarily unavailable (11) >> rsync error: error in IPC code (code 14) at >> /home/lapo/package/rsync-3.0.9-1/src/rsync-3.0.9/pipe.c(63) [sender=3.0.9] >> hostname1: updating of hostname1 finished I've the same system same problem. I usually do a fresh install every 4 or 6 months. I cannot tell that cygiconv-2.dll is the only one that triggers this, but recently (15 days) yes (in older times, cyggcc_s-1.dll was also often in the message). But the process in cause varies: sh, tcsh, gcc-4 etc. rsync i don't think so. >> >> I've tried "rebaseall", and that only moved the address reported for >> cygiconv-2.dll. Even tried "rebaseall -b 0x6800" and "rebaseall -b >> 0x7800". Again, the only effect was to change the address where >> cygiconv-2.dll wants to load. Me too. Exactly the same. I've also instrumented cygwin1.dll as suggested recently to Heiko Elger in http://cygwin.com/ml/cygwin/2012-02/msg00092.html (note that he was also talking cygiconv-2.dll) and i installed Sleep(360L) (1 hour) to have plenty of time. Observations are: - now that i expect fork failures, they seem to appear less often... - the launching of my X session (xinit) is blocked by a 2nd XWin.exe that presumably now waits 1hour to die, if i kill it directly from TaskManager, all is fine, but this is another subject... - the /proc//maps of the processes involved in the fork failure look normal: ... 61262000-6147 rw-p 00262000 C095:C492 13792273859134500 /usr/bin/cygwin1.dll 674C-674C1000 r--p C095:C492 2251799814315820 /usr/bin/cygiconv-2.dll 674C1000-674D8000 r-xp 1000 C095:C492 2251799814315820 /usr/bin/cygiconv-2.dll 674D8000-675B8000 rw-p 00018000 C095:C492 2251799814315820 /usr/bin/cygiconv-2.dll 675B8000-675B9000 r--p 000F8000 C095:C492 2251799814315820 /usr/bin/cygiconv-2.dll 675B9000-675BB000 rw-p 000F9000 C095:C492 2251799814315820 /usr/bin/cygiconv-2.dll 675BB000-675BC000 r--p 000FB000 C095:C492 2251799814315820 /usr/bin/cygiconv-2.dll 6AFC-6AFC1000 r--p C095:C492 1407374884189126 /usr/bin/cygreadline7.dll ... Now looking into dll_init.cc, i'm probably going to try the following: if VirtualAlloc (line 429, just before 'already occupied') fails, try it once more after waiting, say 100ms. Any comments? Regards, Denis Excoffier. -- 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.10-1 fork - address space needed by ... already in use
On 2012-02-07 17:47, Ryan Johnson wrote:
> On 07/02/2012 11:14 AM, Corinna Vinschen wrote:
>> On Feb 7 16:43, Denis Excoffier wrote:
>>> I've also instrumented cygwin1.dll as suggested recently to Heiko Elger
>>> in http://cygwin.com/ml/cygwin/2012-02/msg00092.html
>>> [...]
>>> - the /proc//maps of the processes involved in the fork failure look
>>> normal:
>>> ...
>>> 61262000-6147 rw-p 00262000 C095:C492 13792273859134500
>>> /usr/bin/cygwin1.dll
>>> 674C-674C1000 r--p C095:C492 2251799814315820
>>> /usr/bin/cygiconv-2.dll
>>> 674C1000-674D8000 r-xp 1000 C095:C492 2251799814315820
>>> /usr/bin/cygiconv-2.dll
>>> 674D8000-675B8000 rw-p 00018000 C095:C492 2251799814315820
>>> /usr/bin/cygiconv-2.dll
>>> 675B8000-675B9000 r--p 000F8000 C095:C492 2251799814315820
>>> /usr/bin/cygiconv-2.dll
>>> 675B9000-675BB000 rw-p 000F9000 C095:C492 2251799814315820
>>> /usr/bin/cygiconv-2.dll
>>> 675BB000-675BC000 r--p 000FB000 C095:C492 2251799814315820
>>> /usr/bin/cygiconv-2.dll
>>> 6AFC-6AFC1000 r--p C095:C492 1407374884189126
>>> /usr/bin/cygreadline7.dll
>>> ...
>> If this is the map of the forked child, then it's not exactly normal.
>> Consider that dll_list::reserve_space tries to reserve the memory which
>> is later supposed to be used for cygiconv-2.dll, but apparently
>> cygiconv-2.dll is already loaded.
>>
>> What your report is missing is a bit more information. We external
>> observes don't know if the error message in reserve_space actually
>> reported the address 0x674C, and we also don't know if the parent
>> process has the same layout as the child, or if it's different. The
>> above information alone is not enough to evaluate the situation around
>> cygiconv-2.dll in your scenario.
>>
>>> Now looking into dll_init.cc, i'm probably going to try the following: if
>>> VirtualAlloc (line 429, just before 'already occupied') fails, try it
>>> once more after waiting, say 100ms. Any comments?
>> Don't, it won't help. Assuming my above assumptions are correct (but we
>> need proof), we seem to have a situation like this:
>>
>> - cygiconv-2.dll has been loaded before cygwin1.dll
>>
>> - cygwin1.dll tries to reserve space for later loading of cygiconv-2.dll
>> but cygiconv-2.dll is already where it belongs.
>>
>> - Since rsync is linked against cygiconv-2.dll, I'm wondering
>> why it's in the list of runtime loaded DLLs.
> Denis, could you recompile cygwin1.dll to print out the list of dlls, and
> their types, on fork failure? IIRC, the list is pretty easy to traverse
> (singly-linked list rooted in a global variable or something similar). That
> might confirm or rule out Corinna's hypothesis.
You mean, something like this:
void
dll_list::reserve_space ()
{
for (dll* d = dlls.istart (DLL_LOAD); d; d = dlls.inext ())
#ifdef PRISTINE
if (!VirtualAlloc (d->handle, d->image_size, MEM_RESERVE, PAGE_NOACCESS))
fabort ("address space needed by '%W' (%p) is already occupied",
d->modname, d->handle);
#else
#define TYPE_SHOW(x) ((x) == DLL_NONE) ? "DLL_NONE" : ((x) == DLL_LINK) ?
"DLL_LINK" : ((x) == DLL_LOAD) ? "DLL_LOAD" : ((x) == DLL_ANY) ? "DLL_ANY" :
"DLL_(unknown)"
if (!VirtualAlloc (d->handle, d->image_size, MEM_RESERVE, PAGE_NOACCESS)) {
#if 0
for (dll* d_alt = dlls.istart (DLL_ANY); d_alt; d_alt = dlls.inext ()) {
system_printf ("address space needed by '%W' (%p with type %d=%s) is
perhaps already occupied",
d_alt->modname, d_alt->handle, d_alt->type, TYPE_SHOW(d_alt->type));
};
#else
for (dll* d_alt = dlls.start.next; d_alt; d_alt = d_alt.next ()) {
system_printf ("address space needed by '%W' (%p with type %d=%s) is
perhaps already occupied",
d_alt->modname, d_alt->handle, d_alt->type, TYPE_SHOW(d_alt->type));
};
#endif
fabort ("address space needed by '%W' (%p) is already occupied",
d->modname, d->handle);
};
#endif
}
By the way, if someone can explain why in dll_init.h we have
dll *istart (dll_type t)
{
hold_type = t;
hold = &start;
return inext ();
}
and not
dll *istart (dll_type t)
{
hold_type = t;
hold = &start;
return hold;
}
Regards,
Denis Excoffier.
--
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.10-1 fork - address space needed by ... already in use
On Tue, Feb 07, 2012 at 11:48:35PM +0100, Denis Excoffier wrote:
>>
>> On 2012-02-07 17:47, Ryan Johnson wrote:
>> > On 07/02/2012 11:14 AM, Corinna Vinschen wrote:
>> >> On Feb 7 16:43, Denis Excoffier wrote:
>> >>> I've also instrumented cygwin1.dll as suggested recently to Heiko Elger
>> >>> in http://cygwin.com/ml/cygwin/2012-02/msg00092.html
>> >>> [...]
>> >>> - the /proc//maps of the processes involved in the fork failure
>> >>> look normal:
>> >>> ...
>> >>> 61262000-6147 rw-p 00262000 C095:C492 13792273859134500
>> >>> /usr/bin/cygwin1.dll
>> >>> 674C-674C1000 r--p C095:C492 2251799814315820
>> >>> /usr/bin/cygiconv-2.dll
>> >>> 674C1000-674D8000 r-xp 1000 C095:C492 2251799814315820
>> >>> /usr/bin/cygiconv-2.dll
>> >>> 674D8000-675B8000 rw-p 00018000 C095:C492 2251799814315820
>> >>> /usr/bin/cygiconv-2.dll
>> >>> 675B8000-675B9000 r--p 000F8000 C095:C492 2251799814315820
>> >>> /usr/bin/cygiconv-2.dll
>> >>> 675B9000-675BB000 rw-p 000F9000 C095:C492 2251799814315820
>> >>> /usr/bin/cygiconv-2.dll
>> >>> 675BB000-675BC000 r--p 000FB000 C095:C492 2251799814315820
>> >>> /usr/bin/cygiconv-2.dll
>> >>> 6AFC-6AFC1000 r--p C095:C492 1407374884189126
>> >>> /usr/bin/cygreadline7.dll
>> >>> ...
>> >> If this is the map of the forked child, then it's not exactly normal.
>> >> Consider that dll_list::reserve_space tries to reserve the memory which
>> >> is later supposed to be used for cygiconv-2.dll, but apparently
>> >> cygiconv-2.dll is already loaded.
>> >>
>> >> What your report is missing is a bit more information. We external
>> >> observes don't know if the error message in reserve_space actually
>> >> reported the address 0x674C, and we also don't know if the parent
>> >> process has the same layout as the child, or if it's different. The
>> >> above information alone is not enough to evaluate the situation around
>> >> cygiconv-2.dll in your scenario.
>> >>
>> >>> Now looking into dll_init.cc, i'm probably going to try the following: if
>> >>> VirtualAlloc (line 429, just before 'already occupied') fails, try it
>> >>> once more after waiting, say 100ms. Any comments?
>> >> Don't, it won't help. Assuming my above assumptions are correct (but we
>> >> need proof), we seem to have a situation like this:
>> >>
>> >> - cygiconv-2.dll has been loaded before cygwin1.dll
>> >>
>> >> - cygwin1.dll tries to reserve space for later loading of cygiconv-2.dll
>> >> but cygiconv-2.dll is already where it belongs.
>> >>
>> >> - Since rsync is linked against cygiconv-2.dll, I'm wondering
>> >> why it's in the list of runtime loaded DLLs.
>> > Denis, could you recompile cygwin1.dll to print out the list of dlls, and
>> > their types, on fork failure? IIRC, the list is pretty easy to traverse
>> > (singly-linked list rooted in a global variable or something similar).
>> > That might confirm or rule out Corinna's hypothesis.
>> You mean, something like this:
>>
>> void
>> dll_list::reserve_space ()
>> {
>> for (dll* d = dlls.istart (DLL_LOAD); d; d = dlls.inext ())
>> #ifdef PRISTINE
>> if (!VirtualAlloc (d->handle, d->image_size, MEM_RESERVE, PAGE_NOACCESS))
>> fabort ("address space needed by '%W' (%p) is already occupied",
>> d->modname, d->handle);
>> #else
>> #define TYPE_SHOW(x) ((x) == DLL_NONE) ? "DLL_NONE" : ((x) == DLL_LINK) ?
>> "DLL_LINK" : ((x) == DLL_LOAD) ? "DLL_LOAD" : ((x) == DLL_ANY) ? "DLL_ANY" :
>> "DLL_(unknown)"
>> if (!VirtualAlloc (d->handle, d->image_size, MEM_RESERVE,
>> PAGE_NOACCESS)) {
>> #if 0
>> for (dll* d_alt = dlls.istart (DLL_ANY); d_alt; d_alt = dlls.inext ())
>> {
>> system_printf ("address space needed by '%W' (%p with type %d=%s) is
>> perhaps already occupied",
>> d_alt->modname, d_alt->handle, d_alt->type,
>> TYPE_SHOW(d_alt->type));
>> };
>> #else
>> for (dll* d_alt = d
Re: cygwin-1.7.10-1 fork - address space needed by ... already in use
On Wed, Feb 08, 2012 at 10:27:11AM +0100, Corinna Vinschen wrote: >> On Feb 8 10:08, Denis Excoffier wrote: >> > Result is: >> > >> > 1 [main] gcc-4 4084 dll_list::reserve_space: address space needed by >> > 'cygiconv-2.dll' (0x674C with type 1=DLL_LINK) is perhaps already >> > occupied >> >1720 [main] gcc-4 4084 dll_list::reserve_space: address space needed by >> > 'cygintl-8.dll' (0x6F5C with type 1=DLL_LINK) is perhaps already >> > occupied >> >2085 [main] gcc-4 4084 dll_list::reserve_space: address space needed by >> > 'cygiconv-2.dll' (0x674C with type 2=DLL_LOAD) is perhaps already >> > occupied >> >2440 [main] gcc-4 4084 dll_list::reserve_space: address space needed by >> > 'cygintl-8.dll' (0x6F5C with type 2=DLL_LOAD) is perhaps already >> > occupied >> >> So both DLLs are in the list twice at the same spot with only different >> load types? >> >> Don't be afraid, but I have to ask a difficult question: Huh? >> >> How did that happen? And why doesn't that occur on all systems but only >> on some?!? I can reproduce. On my system (2012-02-07 snapshot instrumented), the following is able to exercise the fork failure any time. I do this from within a dedicated directory named "stc". Current shell seems indifferent. Here it is /bin/tcsh and i've tried with /bin/bash with the same result. % cat doit1 #!/usr/bin/tcsh -f setenv PATH "/usr/bin" cp /usr/bin/cyggcc_s-1.dll . ls rm cyggcc_s-1.dll % % cat doit2 #!/tmp/tcsh -f setenv PATH "/usr/bin" cp /usr/bin/cyggcc_s-1.dll . ls rm cyggcc_s-1.dll % Also you will need to do (once): cp /usr/bin/tcsh.exe /tmp/tcsh.exe % ./doit1 cyggcc_s-1.dll doit1 doit2 % % ./doit2 1 [main] tcsh 3660 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (0x674C with type 1=DLL_LINK) 97 [main] tcsh 3660 dll_list::reserve_space: address space needed by 'cyggcc_s-1.dll' (0x6BF4 with type 1=DLL_LINK) 165 [main] tcsh 3660 dll_list::reserve_space: address space needed by 'cygncurses-10.dll' (0x6958 with type 1=DLL_LINK) 231 [main] tcsh 3660 dll_list::reserve_space: address space needed by 'cygcatgets1.dll' (0x7020 with type 1=DLL_LINK) 298 [main] tcsh 3660 dll_list::reserve_space: address space needed by 'cyggcc_s-1.dll' (0x6BF4 with type 2=DLL_LOAD) 376 [main] tcsh 3660 child_info_fork::abort: address space needed by 'cyggcc_s-1.dll' (0x6BF4) is already occupied [in the background, and this order: - cp /proc/3660/maps /tmp/3660 - kill 3660 from TaskManager (or wait for 3600s) ] 4 [main] tcsh 1756 fork: child -1 - forked process died unexpectedly, retry 0, exit code 1, errno 11 No more processes. % cd .. % rm stc/cyg* % cd stc % cat /tmp/3660 0001-00011000 rw-p : 0 0002-00021000 rw-p : 0 0003-0020B000 ===p : 0 [stack (tid 3504)] 0020B000-0020C000 rw-g 001DB000 : 0 [stack (tid 3504)] 0020C000-0023 rw-p 001DC000 : 0 [stack (tid 3504)] 0023-00233000 r--s : 0 0024-00244000 rw-p : 0 00244000-0034 ===p 4000 : 0 0034-00346000 rw-p : 0 [win heap 0 default grow] 00346000-0035 ===p 6000 : 0 [win heap 0 default grow] 0035-00353000 rw-s : 0 [win heap 1 grow] 00353000-0036 ===s 3000 : 0 [win heap 1 grow] 0036-00376000 r--s C095:C492 281474976712054 /cygdrive/d/WINDOWS/system32/unicode.nls 0038-003C1000 r--s C095:C492 281474976713091 /cygdrive/d/WINDOWS/system32/locale.nls 003D-003D6000 r--s C095:C492 281474976713631 /cygdrive/d/WINDOWS/system32/sorttbls.nls 0040-00401000 r--p C095:C492 22517998136868557 /tmp/tcsh.exe 00401000-00444000 r-xp 1000 C095:C492 22517998136868557 /tmp/tcsh.exe 00444000-00467000 rw-p 00044000 C095:C492 22517998136868557 /tmp/tcsh.exe 0047-004B1000 r--s C095:C492 281474976713630 /cygdrive/d/WINDOWS/system32/sortkey.nls 004C-006BB000 ===p : 0 [stack (tid 1520)] 006BB000-006BC000 rw-g 001FB000 : 0 [stack (tid 1520)] 006BC000-006C rw-p 001FC000 : 0 [stack (tid 1520)] 2000-2007 rw-p : 0 [heap] 2007-3800 ===p 0007 : 0 [heap] 60
Re: cygwin-1.7.10-1 fork - address space needed by ... already in use
On Wed, Feb 08, 2012 at 02:35:02PM +0100, Corinna Vinschen wrote: >> On Feb 8 14:00, Corinna Vinschen wrote: >> > On Feb 8 11:22, Denis Excoffier wrote: >> > > I can reproduce. >> > > >> > > On my system (2012-02-07 snapshot instrumented), the following is able >> > > to exercise the fork failure any time. >> > > >> > > I do this from within a dedicated directory named "stc". >> > > Current shell seems indifferent. Here it is /bin/tcsh and >> > > i've tried with /bin/bash with the same result. >> > > >> > > % cat doit1 >> > > #!/usr/bin/tcsh -f >> > > setenv PATH "/usr/bin" >> > > cp /usr/bin/cyggcc_s-1.dll . >> > > ls >> > > rm cyggcc_s-1.dll >> > > % >> > > % cat doit2 >> > > #!/tmp/tcsh -f >> > > setenv PATH "/usr/bin" >> > > cp /usr/bin/cyggcc_s-1.dll . >> > > ls >> > > rm cyggcc_s-1.dll >> > > % >> > > >> > > Also you will need to do (once): cp /usr/bin/tcsh.exe /tmp/tcsh.exe >> > > >> > > >> > > % ./doit1 >> > > cyggcc_s-1.dll doit1 doit2 >> > > % >> > > % ./doit2 >> > > 1 [main] tcsh 3660 dll_list::reserve_space: address space needed >> > > by 'cygiconv-2.dll' (0x674C with type 1=DLL_LINK) >> > > [...etc...] >> > >> > Thanks for the testcase! I can reproduce now as well. I think I see >> > what's going wrong, but I'm not quite sure what the best fix is. Stay >> > tuned. >> >> What happens in this testcase is that Cygwin checks the full DLL path >> and then finds that the new path to cyggcc_s-1.dll is not the same as >> the path it has already loaded. Therefore it assumes that it has to add >> the file to list. >> >> This is plainly wrong, because, as you can read on >> http://msdn.microsoft.com/en-us/library/ms682586%28v=vs.85%29.aspx the >> Windows loader does not load a DLL again, if it already has a module >> loaded which has the same basename. Therefore the test for the full >> pathname in Cygwin has to to be replaced with only testing the module >> basename. >> >> However, while this situation in the doit2 testcase is simply explained, >> I don't see how this affects your rsync call. >> >> Denis, can you please change your test output? Instead of printing only >> d_alt->modname, please print d_alt->name and then run your rsync test >> again. If this is the same problem as in the doit testcase, I'd like to >> see where the second cygiconv-2.dll is coming from. In theory, if you >> have only a single installation of cygiconv-2.dll, this should'nt >> happen. Here it is. Enjoy! 1 [main] gcc-4 5440 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (file D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygiconv-2.dll) (0x674C with type 1=DLL_LINK) 1580 [main] gcc-4 5440 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (file D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygintl-8.dll) (0x6F5C with type 1=DLL_LINK) 1899 [main] gcc-4 5440 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (file \\?\D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygiconv-2.dll) (0x674C with type 2=DLL_LOAD) 2562 [main] gcc-4 5440 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (file \\?\D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygintl-8.dll) (0x6F5C with type 2=DLL_LOAD) 3290 [main] gcc-4 5440 child_info_fork::abort: address space needed by 'cygiconv-2.dll' (0x674C) is already occupied 2 [main] gcc 3408 fork: child -1 - forked process died unexpectedly, retry 0, exit code 1, errno 11 I don't think you will need /proc/5440/maps this time. Regards, Denis. -- 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.10-1 fork - address space needed by ... already in use
On Wed, Feb 08, 2012 at 03:05:33PM +, Heiko Elger wrote:
>> Denis Excoffier writes:
>>
>> > Here it is. Enjoy!
>> > 1 [main] gcc-4 5440 dll_list::reserve_space: address space needed
>> by 'cygiconv-2.dll' (file
>> > D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygiconv-2.dll) (0x674C with
>> type 1=DLL_LINK)
>> >1580 [main] gcc-4 5440 dll_list::reserve_space: address space needed
>> by 'cygintl-8.dll' (file
>> > D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygintl-8.dll) (0x6F5C with
>> type 1=DLL_LINK)
>> >1899 [main] gcc-4 5440 dll_list::reserve_space: address space needed
>> by 'cygiconv-2.dll' (file
>> > \\?\D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygiconv-2.dll) (0x674C
>> with type 2=DLL_LOAD)
>> >2562 [main] gcc-4 5440 dll_list::reserve_space: address space needed
>> by 'cygintl-8.dll' (file
>> > \\?\D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygintl-8.dll) (0x6F5C
>> with type 2=DLL_LOAD)
>> >3290 [main] gcc-4 5440 child_info_fork::abort: address space needed
>> by 'cygiconv-2.dll' (0x674C)
>> > is already occupied
>> > 2 [main] gcc 3408 fork: child -1 - forked process died unexpectedly,
>> retry 0, exit code 1, errno 11
>> >
>>
>> Hello Denis,
>>
>> thanks a lot for your testing ...
>>
>> Is is possible to send me the snapshot patches responsible for this output.
Here it is (attached).
Good luck.
Denis Excoffier.
diff -cNr 0/dll_init.cc 1/dll_init.cc
*** 0/dll_init.cc Wed Feb 8 16:10:49 2012
--- 1/dll_init.cc Wed Feb 8 16:17:40 2012
***
*** 426,434
dll_list::reserve_space ()
{
for (dll* d = dlls.istart (DLL_LOAD); d; d = dlls.inext ())
! if (!VirtualAlloc (d->handle, d->image_size, MEM_RESERVE, PAGE_NOACCESS))
fabort ("address space needed by '%W' (%p) is already occupied",
d->modname, d->handle);
}
/* Reload DLLs after a fork. Iterates over the list of dynamically loaded
--- 426,440
dll_list::reserve_space ()
{
for (dll* d = dlls.istart (DLL_LOAD); d; d = dlls.inext ())
! #define TYPE_SHOW(x) ((x) == DLL_NONE) ? "DLL_NONE" : ((x) == DLL_LINK) ?
"DLL_LINK" : ((x) == DLL_LOAD) ? "DLL_LOAD" : ((x) == DLL_ANY) ? "DLL_ANY" :
"DLL_(unknown)"
! if (!VirtualAlloc (d->handle, d->image_size, MEM_RESERVE, PAGE_NOACCESS))
{
! for (dll* d_alt = dlls.start.next; d_alt; d_alt = d_alt->next) {
! system_printf ("address space needed by '%W' (file %W) (%p with type
%d=%s)",
! d_alt->modname, d_alt->name, d_alt->handle, d_alt->type,
TYPE_SHOW(d_alt->type));
! };
fabort ("address space needed by '%W' (%p) is already occupied",
d->modname, d->handle);
+ };
}
/* Reload DLLs after a fork. Iterates over the list of dynamically loaded
--
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.10-1 fork - address space needed by ... already in use
On Thu, Feb 09, 2012 at 12:06:31PM +0100, Corinna Vinschen wrote: >> On Feb 8 16:16, Corinna Vinschen wrote: >> > On Feb 8 15:55, Denis Excoffier wrote: >> > > On Wed, Feb 08, 2012 at 02:35:02PM +0100, Corinna Vinschen wrote: >> > > >> Denis, can you please change your test output? Instead of printing >> > > >> only >> > > >> d_alt->modname, please print d_alt->name and then run your rsync test >> > > >> again. If this is the same problem as in the doit testcase, I'd like >> > > >> to >> > > >> see where the second cygiconv-2.dll is coming from. In theory, if you >> > > >> have only a single installation of cygiconv-2.dll, this should'nt >> > > >> happen. >> > > Here it is. Enjoy! >> > > 1 [main] gcc-4 5440 dll_list::reserve_space: address space needed >> > > by 'cygiconv-2.dll' (file >> > > D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygiconv-2.dll) (0x674C >> > > with type 1=DLL_LINK) >> > >1580 [main] gcc-4 5440 dll_list::reserve_space: address space needed >> > > by 'cygintl-8.dll' (file >> > > D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygintl-8.dll) (0x6F5C >> > > with type 1=DLL_LINK) >> > >1899 [main] gcc-4 5440 dll_list::reserve_space: address space needed >> > > by 'cygiconv-2.dll' (file >> > > \\?\D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygiconv-2.dll) >> > > (0x674C with type 2=DLL_LOAD) >> > >2562 [main] gcc-4 5440 dll_list::reserve_space: address space needed >> > > by 'cygintl-8.dll' (file >> > > \\?\D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygintl-8.dll) (0x6F5C >> > > with type 2=DLL_LOAD) >> > >3290 [main] gcc-4 5440 child_info_fork::abort: address space needed >> > > by 'cygiconv-2.dll' (0x674C) is already occupied >> > > 2 [main] gcc 3408 fork: child -1 - forked process died >> > > unexpectedly, retry 0, exit code 1, errno 11 >> > > >> > > I don't think you will need /proc/5440/maps this time. >> > >> > Nope, thank you. Look at this: >> > >> > D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygiconv-2.dll >> > \\?\D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygiconv-2.dll >> > >> > So it's the same DLL path, just one time with the long pathname prefix >> > (or better: The Win32 equivalent to the native NT path prefix). But, >> > as I wrote in my mail to Heiko, neither the Windows loader nor the >> > GetModuleFileName call normalize the path. So I think I just apply >> > my patch to use only the basename in the dll_init code. >> >> I applied a patch and generated a new snapshot. Please give it a try. Usually after installation of a new snapshot i begin with a compilation of the sources. Today the compilation fails in winsup/cygwin/mkimport (perl script) with the following messages: 1 [main] perl 2380 child_info_fork::abort: unable to map Glob.dll, Win32 error 126 4 [main] perl 5460 child_info_fork::abort: unable to map Cwd.dll, Win32 error 126 5 [main] perl 5916 child_info_fork::abort: unable to map Glob.dll, Win32 error 126 4 [main] perl 4028 child_info_fork::abort: unable to map Cwd.dll, Win32 error 126 4 [main] perl 4900 child_info_fork::abort: unable to map Glob.dll, Win32 error 126 4 [main] perl 2128 child_info_fork::abort: unable to map Cwd.dll, Win32 error 126 4 [main] perl 5120 child_info_fork::abort: unable to map Glob.dll, Win32 error 126 4 [main] perl 5440 child_info_fork::abort: unable to map Cwd.dll, Win32 error 126 4 [main] perl 5044 child_info_fork::abort: unable to map Glob.dll, Win32 error 126 4 [main] perl 5456 child_info_fork::abort: unable to map Cwd.dll, Win32 error 126 etc. at the pace one message each 5seconds. All processes indicated remain in /proc, as , and with maps "permission denied". Regards. Denis Excoffier. -- 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.10-1 fork - address space needed by ... already in use
On Thu, Feb 09, 2012 at 02:37:58PM +0059, Denis Excoffier wrote: >> >> Usually after installation of a new snapshot i begin with a compilation >> of the sources. Today the compilation fails in winsup/cygwin/mkimport >> (perl script) with the following messages: >> 1 [main] perl 2380 child_info_fork::abort: unable to map Glob.dll, >> Win32 error 126 >> 4 [main] perl 5460 child_info_fork::abort: unable to map Cwd.dll, >> Win32 error 126 >> 5 [main] perl 5916 child_info_fork::abort: unable to map Glob.dll, >> Win32 error 126 >> 4 [main] perl 4028 child_info_fork::abort: unable to map Cwd.dll, >> Win32 error 126 >> 4 [main] perl 4900 child_info_fork::abort: unable to map Glob.dll, >> Win32 error 126 >> 4 [main] perl 2128 child_info_fork::abort: unable to map Cwd.dll, >> Win32 error 126 >> 4 [main] perl 5120 child_info_fork::abort: unable to map Glob.dll, >> Win32 error 126 >> 4 [main] perl 5440 child_info_fork::abort: unable to map Cwd.dll, >> Win32 error 126 >> 4 [main] perl 5044 child_info_fork::abort: unable to map Glob.dll, >> Win32 error 126 >> 4 [main] perl 5456 child_info_fork::abort: unable to map Cwd.dll, >> Win32 error 126 >> etc. >> >> at the pace one message each 5seconds. >> All processes indicated remain in /proc, as , and with >> maps "permission denied". The parent process can have its maps displayed, it contains: ... 5416D000-54177000 r--p 0016D000 C095:C492 562949954111930 /usr/bin/cygperl5_10.dll 5421-54211000 r--p C095:C492 562949954112306 /usr/lib/perl5/5.10/i686-cygwin/auto/Cwd/Cwd.dll 54211000-54214000 r-xp 1000 C095:C492 562949954112306 /usr/lib/perl5/5.10/i686-cygwin/auto/Cwd/Cwd.dll 54214000-54215000 rw-p 4000 C095:C492 562949954112306 /usr/lib/perl5/5.10/i686-cygwin/auto/Cwd/Cwd.dll 54215000-54216000 r--p 5000 C095:C492 562949954112306 /usr/lib/perl5/5.10/i686-cygwin/auto/Cwd/Cwd.dll 54216000-54218000 rw-p 6000 C095:C492 562949954112306 /usr/lib/perl5/5.10/i686-cygwin/auto/Cwd/Cwd.dll 54218000-54219000 r--p 8000 C095:C492 562949954112306 /usr/lib/perl5/5.10/i686-cygwin/auto/Cwd/Cwd.dll 54219000-5421A000 rw-p 9000 C095:C492 562949954112306 /usr/lib/perl5/5.10/i686-cygwin/auto/Cwd/Cwd.dll 5421A000-5421C000 r--p A000 C095:C492 562949954112306 /usr/lib/perl5/5.10/i686-cygwin/auto/Cwd/Cwd.dll 5468-54681000 r--p C095:C492 562949954112354 /usr/lib/perl5/5.10/i686-cygwin/auto/Fcntl/Fcntl.dll ... 54688000-5468A000 r--p 8000 C095:C492 562949954112354 /usr/lib/perl5/5.10/i686-cygwin/auto/Fcntl/Fcntl.dll 5469-54691000 r--p C095:C492 562949954112357 /usr/lib/perl5/5.10/i686-cygwin/auto/File/Glob/Glob.dll 54691000-54695000 r-xp 1000 C095:C492 562949954112357 /usr/lib/perl5/5.10/i686-cygwin/auto/File/Glob/Glob.dll 54695000-54696000 rw-p 5000 C095:C492 562949954112357 /usr/lib/perl5/5.10/i686-cygwin/auto/File/Glob/Glob.dll 54696000-54697000 r--p 6000 C095:C492 562949954112357 /usr/lib/perl5/5.10/i686-cygwin/auto/File/Glob/Glob.dll 54697000-54699000 rw-p 7000 C095:C492 562949954112357 /usr/lib/perl5/5.10/i686-cygwin/auto/File/Glob/Glob.dll 54699000-5469A000 r--p 9000 C095:C492 562949954112357 /usr/lib/perl5/5.10/i686-cygwin/auto/File/Glob/Glob.dll 5469A000-5469B000 rw-p A000 C095:C492 562949954112357 /usr/lib/perl5/5.10/i686-cygwin/auto/File/Glob/Glob.dll 5469B000-5469D000 r--p B000 C095:C492 562949954112357 /usr/lib/perl5/5.10/i686-cygwin/auto/File/Glob/Glob.dll 5470-54701000 r--p C095:C492 562949954112374 /usr/lib/perl5/5.10/i686-cygwin/auto/IO/IO.dll ... and 5421 and 5469 are OK iaw objdump -h I will add that i cannot instrument myself... Regards, Denis Excoffier. -- 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 nodosfilewarning message
Hello, The following command, under tcsh, produces the "nodosfilewarning" message but shouldn't (IMHO). Of course, it seems more tcsh-related than cygwin-related, but perhaps someone could have an idea. % echo '\u' /etc/xi* cygwin warning: MS-DOS style path detected: \u Preferred POSIX equivalent is: /cygdrive/d/u CYGWIN environment variable option "nodosfilewarning" turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames \u /etc/xinetd.conf /etc/xinetd.d % No message under bash (under a fresh instance of cygwin1.dll of course): $ echo '\u' /etc/xi* \u /etc/xinetd.conf /etc/xinetd.d Regards, Denis Excoffier. -- 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.10-1 fork - address space needed by ... already in use
On Sun, Mar 04, 2012 at 06:22:10PM +0100, Corinna Vinschen wrote: >> On Feb 8 11:22, Denis Excoffier wrote: >> > On Wed, Feb 08, 2012 at 10:27:11AM +0100, Corinna Vinschen wrote: >> > >> On Feb 8 10:08, Denis Excoffier wrote: >> > >> > Result is: >> > >> > >> > >> > 1 [main] gcc-4 4084 dll_list::reserve_space: address space >> > >> > needed by 'cygiconv-2.dll' (0x674C with type 1=DLL_LINK) is >> > >> > perhaps already occupied >> > >> >1720 [main] gcc-4 4084 dll_list::reserve_space: address space >> > >> > needed by 'cygintl-8.dll' (0x6F5C with type 1=DLL_LINK) is >> > >> > perhaps already occupied >> > >> >2085 [main] gcc-4 4084 dll_list::reserve_space: address space >> > >> > needed by 'cygiconv-2.dll' (0x674C with type 2=DLL_LOAD) is >> > >> > perhaps already occupied >> > >> >2440 [main] gcc-4 4084 dll_list::reserve_space: address space >> > >> > needed by 'cygintl-8.dll' (0x6F5C with type 2=DLL_LOAD) is >> > >> > perhaps already occupied >> >> Denis, can you please give the latest snapshot DLL a try in all >> circumstances in which you saw the above kind of fork problems in >> 1.7.10? I applied a patch which should now work out the differences >> between linked and loaded DLLs better than before. >> % uname -a CYGWIN_NT-5.1 edited 1.7.12s(0.260/5/3) 20120304 17:49:39 i686 Cygwin % I am now unable to report any problem of that sort. I have compiled the cygwin1.dll, the new gcc-4.7.0-rc-20120302, and several other packages with no occurrence of such a message. I've only to report that i observe some time to time the "something failed for pid" message (see several instances below). "Win32 Error 5" is ERROR_ACCESS_DENIED i suppose (in winerrors.h). I don't know what we are expected to do with these. In addition, they do not seem to hurt much. Also i've to say that i've installed the CYGWIN=detect_bloda and nothing has shown up (still). Regards, Denis Excoffier. 947 [main] sh 660! _pinfo::dup_proc_pipe: something failed for pid 0: res 660, hProcess 0x6C8, wr_proc_pipe 0x758 vs. 0x758, Win32 error 5 2 [main] sh 3360! _pinfo::dup_proc_pipe: something failed for pid 0: res 3360, hProcess 0x6BC, wr_proc_pipe 0x758 vs. 0x758, Win32 error 5 1345 [main] sh 3772! _pinfo::dup_proc_pipe: something failed for pid 0: res 3772, hProcess 0x6CC, wr_proc_pipe 0x758 vs. 0x758, Win32 error 5 2 [main] sh 792! _pinfo::dup_proc_pipe: something failed for pid 0: res 792, hProcess 0x6D0, wr_proc_pipe 0x75C vs. 0x75C, Win32 error 5 1 [main] sh 3328! _pinfo::dup_proc_pipe: something failed for pid 0: res 3328, hProcess 0x6BC, wr_proc_pipe 0x758 vs. 0x758, Win32 error 5 1 [main] sh 1980! _pinfo::dup_proc_pipe: something failed for pid 0: res 1980, hProcess 0x6BC, wr_proc_pipe 0x74C vs. 0x74C, Win32 error 5 1 [main] sh 628! _pinfo::dup_proc_pipe: something failed for pid 0: res 628, hProcess 0x6BC, wr_proc_pipe 0x758 vs. 0x758, Win32 error 5 1 [main] sh 856! _pinfo::dup_proc_pipe: something failed for pid 0: res 856, hProcess 0x6BC, wr_proc_pipe 0x758 vs. 0x758, Win32 error 5 1 [main] tcsh 3300! _pinfo::dup_proc_pipe: something failed for pid 0: res 3300, hProcess 0x6F0, wr_proc_pipe 0x768 vs. 0x768, Win32 error 5 >> >> Thanks, >> 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 -- 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
