Re: native symlinks and non-existent targets
On Wed, Apr 24, 2024 at 10:11:52PM +, Christopher Layne via Cygwin wrote: > Based on past threads I've read I believe the issue is actually with > windows not allowing a symlink to be created with a non-existent target, > but I do know windows does not care if you break a link after the fact. Actually, after referring to some microsoft documentation, is this even true? https://learn.microsoft.com/en-us/windows/win32/fileio/symbolic-link-programming-considerations --- Programming Considerations (Local File Systems) Article 03/03/2021 5 contributors Keep the following programming considerations in mind when working with symbolic links: * Symbolic links can point to a non-existent target. * When creating a symbolic link, the operating system does not check to see if the target exists. * If an application tries to open a non-existent target, ERROR_FILE_NOT_FOUND is returned. * Symbolic links are reparse points. For more information, see Determining Whether a Directory Is a Mounted Folder. * There is a maximum of 63 reparse points (and therefore symbolic links) allowed in a particular path. (Windows Server 2003 and Windows XP: There is a limit of 31 reparse points on any given path.) --- If it isn't true then this seems trivial to fix. -cl -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
native symlinks and non-existent targets
Since I recently sent an email about symlinks and cygdrive mounts, I figured I'd report another issue that's plagued me over the years and that I know others have reported in the past: You can't create native symlinks to non-existent targets and this causes a bunch of issues when rsyncing directories containing symlinks unless one does a multi-pass approach which takes special precautions to sync all the non-symlink contents first and then syncs the symlinks right after (note: this also has its own problems with links to links). Example: clayne@sv590:/tmp/link-test $ ls -la total 32 drwxr-xr-x 1 clayne None 0 Apr 24 14:13 . drwxrwxrwt 1 clayne None 0 Apr 24 14:34 .. lrwxrwxrwx 7 clayne None 3 Apr 24 14:11 _foo -> foo -rw-r--r-- 5 clayne None 0 Apr 24 14:11 foo lrwxrwxrwx 4 clayne None 3 Apr 24 14:13 foo-ln -> foo clayne@sv590:/tmp/link-test $ rsync -vaHSP /tmp/link-test/ /tmp/link-test-sync-test/ sending incremental file list created directory /tmp/link-test-sync-test ./ rsync: [generator] symlink "/tmp/link-test-sync-test/_foo" -> "foo" failed: No such file or directory (2) rsync: [generator] symlink "/tmp/link-test-sync-test/foo-ln" -> "foo" failed: No such file or directory (2) foo 0 100%0.00kB/s0:00:00 (xfr#1, to-chk=1/4) sent 178 bytes received 89 bytes 534.00 bytes/sec total size is 6 speedup is 0.02 rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1336) [sender=3.2.7] clayne@sv590:/tmp/link-test $ rsync -vaHSP /tmp/link-test/ /tmp/link-test-sync-test/ sending incremental file list _foo -> foo foo-ln -> foo sent 134 bytes received 18 bytes 304.00 bytes/sec total size is 6 speedup is 0.04 This only works in a straight-forward manner when using non-native symlinks (which can also _change_ the symlinks such that they're broken/unusable outside of cygwin): clayne@sv590:/tmp/link-test $ rm -rf /tmp/link-test-sync-test clayne@sv590:/tmp/link-test $ CYGWIN= rsync -vaHSP /tmp/link-test/ /tmp/link-test-sync-test/ sending incremental file list created directory /tmp/link-test-sync-test ./ _foo -> foo foo 0 100%0.00kB/s0:00:00 (xfr#1, to-chk=1/4) foo-ln -> foo sent 184 bytes received 95 bytes 558.00 bytes/sec total size is 6 speedup is 0.02 Or another very simple test-case not involving rsync: clayne@sv590:/tmp/link-test $ ln -s this-does-not-exist some-link ln: failed to create symbolic link 'some-link': No such file or directory Relevant sections of an strace for the above: 102 83054 [main] ln 1379 symlink_info::check: 0x0 = NtCreateFile (\??\C:\cygwin64\tmp\link-test) 114 83168 [main] ln 1379 symlink_info::check: not a symlink 91 83259 [main] ln 1379 symlink_info::check: 0 = symlink.check(C:\cygwin64\tmp\link-test, 0x7B140) (mount_flags 0x30008, path_flags 0x0) 92 83351 [main] ln 1379 path_conv::check: this->path(C:\cygwin64\tmp\link-test\this-does-not-exist), has_acls(1) 91 83442 [main] ln 1379 seterrno_from_win_error: /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/path.cc:2063 windows error 2 90 83532 [main] ln 1379 geterrno_from_win_error: windows error 2 == errno 2 83 83615 [main] ln 1379 symlink_worker: -1 = symlink_worker(this-does-not-exist, /tmp/link-test/some-link, 0) However, you _can_ do this: clayne@sv590:/tmp/link-test $ tmp="$(mktemp)" && ln -s "$tmp" some-link && rm -f "$tmp" && ls -la some-link lrwxrwxrwx 1 clayne None 19 Apr 24 14:58 some-link -> /tmp/tmp.o7xpJxaqig And here's a case showing where "hard-linked" symlinks work with non-existent targets: clayne@sv590:/tmp/link-test $ find -type l -print0 | rsync -avSHP --files-from=- --from0 --link-dest=/tmp/link-test /tmp/link-test /tmp/link-test-link-dest building file list ... 3 files to consider created directory /tmp/link-test-link-dest sent 113 bytes received 59 bytes 344.00 bytes/sec total size is 6 speedup is 0.03 clayne@sv590:/tmp/link-test $ ls -l /tmp/link-test-link-dest total 0 lrwxrwxrwx 8 clayne None 3 Apr 24 14:11 _foo -> foo lrwxrwxrwx 5 clayne None 3 Apr 24 14:13 foo-ln -> foo clayne@sv590:/tmp/link-test $ ls -lai _foo /tmp/link-test-link-dest/_foo 48413695994484407 lrwxrwxrwx 8 clayne None 3 Apr 24 14:11 /tmp/link-test-link-dest/_foo -> foo 48413695994484407 lrwxrwxrwx 8 clayne None 3 Apr 24 14:11 _foo -> foo This only works because the symlinks are being straight up cloned and not being newly created on the destination side. This "works" if one is doing a --link-dest of an entire directory to essentially create a hard-linked copy but anything outside of that use case will still require multiple runs. Based on past threads I've read I believe the issue is actually with windows not allowing a symlink to be created with a non-existent target, but I do know windows does not care if you break a link after the fact. For the non-existent target case, is there any way we could just hack-fix this or workaround it at the cygwin layer by create a symlink to a temp
Issue with cygdrive mount, native symlinks, and noacl option
I noticed recently while attempting to rsync directories from one drive to
another that I was getting the familiar "NULL SID", "incorrectly ordered", etc.
type ownership issues on the destination even though I use noacl for cygdrive
mounts (I'm aware of the POSIX vs windows ACL issues, etc. hence why I use
"noacl" for cygdrive). I was able to track down the issue to a specific
combination of things that creates the problem:
1. I have symlinks in / for each drive pointing to /cygdrive/[a-z] via ln -s
/cygdrive/ /.
2. All symlinks are actually native reparse points as a I run with
CYGWIN=winsymlinks:nativestrict by default.
Example:
clayne@sv590:/ $ ls -lad /[a-z]
lrwxrwxrwx 1 clayne None 11 Apr 24 12:24 /c -> /cygdrive/c
lrwxrwxrwx 1 clayne None 11 Apr 24 12:24 /e -> /cygdrive/e
lrwxrwxrwx 1 clayne None 11 Apr 24 12:24 /f -> /cygdrive/f
lrwxrwxrwx 1 clayne None 11 Apr 24 12:24 /s -> /cygdrive/s
3. I issue the rsync with something like: rsync -avSHP /f/some-dir/ /s/some-dir/
The issue here is that it appears mount related options such as noacl are
evaluated differently when native symlinks are used. If I change the
destination to instead be "/cygdrive/s/dest/dir" then noacl works
appropriately. On top of all this, if I instead create the /s symlink as a
"cygwin" style symlink via CYGWIN=winsymlinks things also work correctly - that
is, the noacl option is used. What I would intuitively expect, atleast within
the context of acl vs noacl, is for the symlinks to be resolved first and then
mount options specific to the target resolved based off what the symlink
actually points to. In the native/nativestrict case, it appears to be doing
this in reverse and inheriting /'s standard default acl option rather than
/cygdrive's noacl option.
Footnotes on workarounds:
* I know how to workaround using the root-level symlinks in the first place by
just mounting cygdrive to /, but I'd have to update various scripts which
already use /cygdrive and I like having the "windows drives" self-contained
under /cygdrive (even though I frequently use the / level symlinks as
shorthand).
* I also know how to avoid the issue entirely by using /cygdrive/ for the
destination but the underlying issue still seems like a bug or an oversight to
me, particularly given that nativestrict behaves differently when it comes to
evaluating mount options.
* Another workaround would be to use non-nativestrict symlinks but I want to
preserve interoperability with native windows applications outside of cygwin
and I've learned over the years to just avoid anything that isn't nativestrict.
Here's a repro case:
clayne@sv590:~ $ uname -a
CYGWIN_NT-10.0-19045 sv590 3.5.3-1.x86_64 2024-04-03 17:25 UTC x86_64 Cygwin
clayne@sv590:~ $ cat /tmp/link_test
#!/bin/bash
set -e
set -o pipefail
rm -rf /cygdrive/{f,s}/link_test
mkdir -p /cygdrive/{f,s}/link_test
echo foo > /cygdrive/f/link_test/test
for i in winsymlinks winsymlinks:lnk winsymlinks:sys winsymlinks:nativestrict;
do
export CYGWIN="$i"
link="s_${i//:/_}"
ln -sfT /cygdrive/s /$link
rsync -aSH /f/link_test/ "/$link/link_test/$link"/
ls -la /$link/link_test/$link/test || true
getfacl /$link/link_test/$link/test || true
done
clayne@sv590:~ $ bash -x /tmp/link_test
+ set -e
+ set -o pipefail
+ rm -rf /cygdrive/f/link_test /cygdrive/s/link_test
+ mkdir -p /cygdrive/f/link_test /cygdrive/s/link_test
+ echo foo
+ for i in winsymlinks winsymlinks:lnk winsymlinks:sys winsymlinks:nativestrict
+ export CYGWIN=winsymlinks
+ CYGWIN=winsymlinks
+ link=s_winsymlinks
+ ln -sfT /cygdrive/s /s_winsymlinks
+ rsync -aSH /f/link_test/ /s_winsymlinks/link_test/s_winsymlinks/
+ ls -la /s_winsymlinks/link_test/s_winsymlinks/test
-rw-r--r-- 1 clayne None 4 Apr 24 13:38
/s_winsymlinks/link_test/s_winsymlinks/test
+ getfacl /s_winsymlinks/link_test/s_winsymlinks/test
getfacl: /s_winsymlinks/link_test/s_winsymlinks/test: Not supported
+ true
+ for i in winsymlinks winsymlinks:lnk winsymlinks:sys winsymlinks:nativestrict
+ export CYGWIN=winsymlinks:lnk
+ CYGWIN=winsymlinks:lnk
+ link=s_winsymlinks_lnk
+ ln -sfT /cygdrive/s /s_winsymlinks_lnk
+ rsync -aSH /f/link_test/ /s_winsymlinks_lnk/link_test/s_winsymlinks_lnk/
+ ls -la /s_winsymlinks_lnk/link_test/s_winsymlinks_lnk/test
-rw-r--r-- 1 clayne None 4 Apr 24 13:38
/s_winsymlinks_lnk/link_test/s_winsymlinks_lnk/test
+ getfacl /s_winsymlinks_lnk/link_test/s_winsymlinks_lnk/test
getfacl: /s_winsymlinks_lnk/link_test/s_winsymlinks_lnk/test: Not supported
+ true
+ for i in winsymlinks winsymlinks:lnk winsymlinks:sys winsymlinks:nativestrict
+ export CYGWIN=winsymlinks:sys
+ CYGWIN=winsymlinks:sys
+ link=s_winsymlinks_sys
+ ln -sfT /cygdrive/s /s_winsymlinks_sys
+ rsync -aSH /f/link_test/ /s_winsymlinks_sys/link_test/s_winsymlinks_sys/
+ ls -la /s_winsymlinks_sys/link_test/s_winsymlinks_sys/test
-rw-r--r-- 1 clayne None 4 Apr 24 13:38
/s_winsymlinks_sys/link_test/s_winsymlinks_sys/test
+ getfacl
more busted paths
20070307 snap, was doing it with 0301 as well: 122 85114 [main] maptest 2960 open: open (./test.txt, 0x0) 146 85260 [main] maptest 2960 normalize_posix_path: src ./test.txt 375 85635 [main] maptest 2960 cwdstuff::get: posix /c/WINDOWS 198 85833 [main] maptest 2960 cwdstuff::get: (/c/WINDOWS) = cwdstuff::get (0x22C7B0, 260, 1, 0), errno 0 119 85952 [main] maptest 2960 normalize_posix_path: /c/WINDOWS/test.txt = normalize_posix_path (./test.txt) -- 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: more busted paths
On Wed, Mar 07, 2007 at 07:19:53PM -0500, Christopher Faylor wrote: On Wed, Mar 07, 2007 at 04:14:21PM -0800, Christopher Layne wrote: 20070307 snap, was doing it with 0301 as well: 122 85114 [main] maptest 2960 open: open (./test.txt, 0x0) 146 85260 [main] maptest 2960 normalize_posix_path: src ./test.txt 375 85635 [main] maptest 2960 cwdstuff::get: posix /c/WINDOWS 198 85833 [main] maptest 2960 cwdstuff::get: (/c/WINDOWS) = cwdstuff::get (0x22C7B0, 260, 1, 0), errno 0 119 85952 [main] maptest 2960 normalize_posix_path: /c/WINDOWS/test.txt = normalize_posix_path (./test.txt) I think some words describing what problem you think is being shown above are probably in order. cgf test.txt is in /var/tmp? Sorry, I thought it would be assumed that I probably am not creating test data in c:\windows. Happens under strace and gdb. No cygexec on the mount. -cl -- 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: more busted paths
On Wed, Mar 07, 2007 at 04:49:19PM -0800, Christopher Layne wrote: On Wed, Mar 07, 2007 at 07:19:53PM -0500, Christopher Faylor wrote: I think some words describing what problem you think is being shown above are probably in order. cgf test.txt is in /var/tmp? Sorry, I thought it would be assumed that I probably am not creating test data in c:\windows. Happens under strace and gdb. No cygexec on the mount. Very simple to duplicate btw: strace ls bogus -cl -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin speed
On Fri, Mar 02, 2007 at 11:11:54AM -0800, Brian Dessent wrote: Vinod Gupta wrote: Cygwin was a slow by a factor of 3x. Is that normal? Yes. Emulation of POSIX functions which do not exist on Windows is expensive. Fork is especially bad, which is all you're really testing there. Where is the *continual* fork in his script btw? -cl -- 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: 1.7.0 CVS perl mutex panic
On Tue, Feb 27, 2007 at 05:59:36PM -0600, Brian Ford wrote: FYI $ uname -a CYGWIN_NT-5.1 PC1163-8460-XP 1.7.0(0.166/4/2) 2007-02-26 09:41 i686 unknown unknown Cygwin $ perl --version This is perl, v5.8.7 built for cygwin-thread-multi-64int (with 1 registered patch, see perl -V for more detail) [snip] $ perl -e 'open(x, ls|)' panic: MUTEX_UNLOCK (1) [util.c:2279] at -e line 1. BTW: I also saw this with a make job when I checked out of CVS a couple of days ago. there was a change to mutex handling in the changelogs further back but unfortunately I hadn't done anything to track it down yet. Just chiming in to let it be known that others see this same error as well. -cl -- 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: GDB Ctrl-C Interrupt Fails WORKAROUND
On Thu, Jun 15, 2006 at 11:04:56AM -0400, Christopher Faylor wrote: I'm happy for you that CTRL-C works for you. It does not work for me. I'm almost never running gdb from a genuine DOS command prompt. Sometimes via ssh, sometimes via a terminal emulator. CTRL-C doesn't work in those. Also, if you have tty in your CYGWIN variable it doesn't work even from a DOS command prompt. Which is exactly what I theorized above. So, characterizing CTRL-C as not working in gdb is rather an overstatement without more details. Now you know that you can use a standard console window for debugging and all will be well. Lacking the ability to interrupt a running program severely limits gdb's usefulness. Fortunately there's a workaround available. Yep. Use a console window. cgf Where in the cygwin source tree would the best place be to look for where SIGINT handling is being done at the tty/pty level so that I can remove this pointless limitation from my builds? -cl -- 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: Regarding mount command inside CYGWIN
On Thu, Mar 01, 2007 at 11:13:00AM +0530, Rakesh Kumar wrote: Hello, I'm running a command inside Cygwin mount -b /cygdrive/c/cygwin/rakesh /cygdrive/c/cygwin/rakesh/usr/cygnus But I get the following error? mount: /cygdrive/c/cygwin/rakesh/usr/cygnus: Invalid argument Is the mount command wrongly given?? Regards, Rakesh Yes. You need a win32 path for the mount source. man mount. -cl -- 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: does usleep() sleep more than it's supposed to?
On Mon, Feb 26, 2007 at 03:57:10PM +0800, Carlo Florendo wrote: Good Day, I'm writing an application that requires time precisions up to the microsecond level. However, I put a hard-coded adjustment of 9000 microseconds since usleep() seems to sleep on the average of 9000 microseconds more than it's supposed to, at least on my system. I could work with up to 2000 microseconds for function overhead but 9000 microseconds seems to be too long. Without using POSIX Realtime extensions, you will *never* attain consistent granularity at the microsecond level with any sleep() function. Think about it - on a preemptive multiprocess OS - the minimum intervals the OS uses for handing out timeslices to all processes contained within the current environment (and also the associated forced sleeping of processes who have used too many of their timeslices within a given interval) will always limit your granularity. -cl -- 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: Setting up a ssh service
On Sat, Feb 24, 2007 at 05:10:35PM -0800, Brian Dessent wrote: Web Developer wrote: add a new entry to system variables: New variable name is CYGWIN, variable value is ntsec Why do people keep repeating this chestnut? 'ntsec' is the default. There is no need to have it in CYGWIN. Having CYGWIN=ntsec is a no-op. This does nothing. Brian It's in the SSH doc. BTW: I've had the funky SSH issues before where nothing at all works. My solution was pretty much voodoo based: 1. Delete every single ssh, ssh_server, ssh-related user manually. Delete these users from /etc/passwd as well as the windows side of the things. 2. Delete every dynamically generated ssh file - keys, config, etc. 3. Run ssh-host-config again. -- 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: Setting up a ssh service
On Sun, Feb 25, 2007 at 12:18:31PM -0600, Charles D. Russell wrote: Christopher Layne wrote: BTW: I've had the funky SSH issues before where nothing at all works. My solution was pretty much voodoo based: 1. Delete every single ssh, ssh_server, ssh-related user manually. Delete these users from /etc/passwd as well as the windows side of the things. 2. Delete every dynamically generated ssh file - keys, config, etc. 3. Run ssh-host-config again. I've gotten cygwin ssh to work on my home network, but after it broke for the second time I felt it was just too much hassle to reinstall. For me ssh is a convenience, not a necessity. Would rsh be any easier to maintain? I would gladly trade security for convenience. There's not really much to maintain after you install it the first time. It only takes maybe 20 minutes to work out any inconsistencies. Don't even think of rsh or rlogin. -cl -- 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/
question in regards to cygwin-patches
For some reason, I am unable to send email to cygwin-patches. I am subscribed and all of that, but in trying to get a patch through, it's just not happening. The SMTP handoff is correctly working - the email is getting to sourceware. I get confirm/subscribe messages from ezlm, etc. everything checks out fine there. But no to list e-mail gets past sourceware. -- 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/
cygwin shortcut question
Just noticed something about the shortcut and use of c:\cygwin\bin\cygwin.bat. The contents thereof: -- @echo off C: chdir C:\cygwin\bin bash --login -i -- Now when running this you almost always end up with a cmd.exe also running. I just changed my shortcut to instead be: Target: c:\cygwin\bin\bash.exe --login -i Start in: c:\cygwin\bin Absolutely no issues running this without calling any batch file, is there any reason this isn't the default? -cl -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin shortcut question
On Fri, Feb 23, 2007 at 07:57:41PM -0800, Christopher Layne wrote: Just noticed something about the shortcut and use of c:\cygwin\bin\cygwin.bat. Correction: That should be c:\cygwin\cygwin.bat -- 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: Problems with current snapshot 20070222 ?
On Thu, Feb 22, 2007 at 02:54:50PM +0100, Angelo Graziosi wrote: After installed the snapshot, trying to remove /tmp/usr there is this new problem: cd /tmp ls -lrt ... drwxr-xr-x+ 3 Angelo Administrators0 Feb 22 14:18 usr rm -rf usr/ rm: failed to close directory `usr/' rm: FATAL: failed to close directory `usr//bin': Permission denied or cd /tmp mkdir foo rm -rf foo rm: FATAL: failed to close directory `foo/': Permission denied I have also rebased, and with 0x6500, but this does not help. Might want to warn everyone not to use 20060222. I was also bitten by this snapshot. Back to 20060215 here. -cl -- 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: rsync 2.6.9?
On Thu, Feb 22, 2007 at 01:06:24PM +0100, Frank Fesevur wrote: Hi, November 6th, 2006 was rsync version 2.6.9 released. http://rsync.samba.org/ I assume the maintainer of the rsync package also reads this list. Are there any plans to upgrade the cygwin package, which is 2.6.6 at the moment? The newly added --log-file option would help us a lot. Regards, Frank It's very easy to just download the source and make it yourself btw. -cl -- 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: xargs problem
On Mon, Feb 19, 2007 at 05:34:31PM +0100, Corinna Vinschen wrote: If you want a command run once for each item in a list of things, use a for loop: ...or `xargs -n 1' Corinna Yeah, unfortunately don't try to do too much with that or you'll be waiting for a while. $ uname -a; uptime; time echo 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 | xargs -n1 /dev/null CYGWIN_NT-5.2 opteron 1.7.0s(0.165/4/2) 20070215 07:41:32 i686 Cygwin 10:05:57 up 1 day, 11:10, 0 users, load average: 0.00, 0.00, 0.00 real0m5.185s user0m0.150s sys 0m0.573s $ uname -a; uptime; time echo 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 | xargs -n1 /dev/null Linux ns1 2.6.20 #8 Mon Feb 19 08:03:12 PST 2007 i686 GNU/Linux 10:06am up 1:50, 7 users, load average: 3.08, 4.67, 5.53 real0m0.366s user0m0.012s sys 0m0.080s Gotta love it when a Linux box with *literally* 1/10th the cpu power (Celeron-D 2ghz Prescott core) is compiling KDE, and still knocking off numbers 15x times as fast as my hulked out dual-core Opteron 180. What is that, a ratio of about 150x times slower due to the blazing fork() we have now? -cl -- 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: xargs problem
On Mon, Feb 19, 2007 at 05:34:31PM +0100, Corinna Vinschen wrote: maybe I'm being dense, but xargs does not seem to do what it should: xargs only calls the command (echo in this case) once, with all the given arguments. (It will call it more than once only if calling it once would be a too-long command line.) If you want a command run once for each item in a list of things, use a for loop: ...or `xargs -n 1' Which btw is obnoxiously slow on Cygwin for some weird-unknown reason. A better alternative to xargs on cygwin: printf %s\n `command` -- 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: xargs problem
On Mon, Feb 19, 2007 at 01:04:38PM -0800, Shankar Unni wrote: Christopher Layne wrote: $ uname -a; uptime; time echo 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 | xargs -n1 /dev/null CYGWIN_NT-5.2 opteron 1.7.0s(0.165/4/2) 20070215 07:41:32 i686 Cygwin 10:05:57 up 1 day, 11:10, 0 users, load average: 0.00, 0.00, 0.00 real0m5.185s user0m0.150s sys 0m0.573s [OT] On an Opteron?! I get 1.1 seconds on a low-end Core 2 Duo with WinXP. Something else also the matter at your end. (Of course, my Linux box, on an older Core Duo, also does this in 0.085 seconds, so your Linux box is slow, too :-) ). The Linux box is only a Prescott Celeron-D. It's not that bad when it isn't loaded, under .1s, but those comparisons aren't even the issue really. But process creation is well-known to be slow in Cygwin, for completely unavoidable reasons (having to emulate a nearly full layer of POSIX semantics *on top of* Windows processes, which are already slow(er) to start with). Absolutely. I don't disagree with this. The issue is the magnitude. The opteron box has 4gigs of ram, scsi 320 disks, and is running water cooled at 2.8 ghz. Nothing *normal* can explain such a reason why a Celeron-D can fork the same /bin/echo's 15 times faster than that box, except for the OS difference. Even then, the difference is insane. I'm running the latest snapshot, no funky virus or other crap that could get in the way, 7 items in my path (might as well handle stat() while we're there), I've tried pointing out in the past that I believe something is going awry here: 70 288 [main] xargs 5956 child_copy: dll data - hp 0x6C8 low 0x61118000, high 0x6111D040, res 1 75657 75945 [main] xargs 5956 child_copy: dll bss - hp 0x6C8 low 0x61175000, high 0x6117EC30, res 1 ^ 903 76848 [main] xargs 5956 child_copy: user heap - hp 0x6C8 low 0xA2, high 0xA4, res 1 | 44 76892 [main] xargs 5956 child_copy: done | 44 76936 [main] xargs 5956 child_copy: data - hp 0x6C8 low 0x406000, high 0x406050, res 1 | 29 76965 [main] xargs 5956 child_copy: bss - hp 0x6C8 low 0x409000, high 0x4093A0, res 1 | 21 76986 [main] xargs 5956 child_copy: done | |__ not normal 10569 98670 [main] xargs 5956 wait_for_sigthread: process/signal handling enabled, state 0x41 [...] 8850 107734 [sig] xargs 5956 wait_sig: signalling pack.wakeup 0x664 6149 113883 [main] xargs 5956 sig_send: returning 0x0 from sending signal -34 89 113972 [main] xargs 5956 open: open (/dev/null, 0x0) 220 114192 [main] xargs 5956 normalize_posix_path: src /dev/null 25649 114298 [main] xargs 9760 proc_subproc: finished processing terminated/stopped child 25kusec to handle that? Other stuff as welll that just plain sticks out: 314 94499 [main] echo 5956 pinfo::exit: Calling ExitProcess n 0x0, exitcode 0x0 124272 240263 [proc_waiter] xargs 9760 pinfo::maybe_set_exit_code_from_windows: pid 5956, exit value - old 0x800, windows 0xDEADBEEF, cygwin 0x800 The costs may appear small, but they snowball down the chain. If it takes 75kusec to fire off a bss copy, times 100 = 7500kusec in the worst case. Even if I was hitting 20kusec per each, it's still 2 seconds. Here, try yours: echo 0 1 2 3 4 5 6 9 bogue strace xargs -n1 bogue | egrep 'child_copy:' -cl -- 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: strange bug in gettimeofday function
On Mon, Feb 19, 2007 at 12:52:10PM -0800, Shankar Unni wrote:
Andrew Makhorin wrote:
{ double t0 = get_time(), t1 = get_time();
[Maybe OT?]
1. I can't remember if C guarantees that comma-separated *declarations*
are initialized in order or not.. And to think I used to be an ANSI C
guru :-(.
Should be fine in this case.
2. The reason that the t0 t1 fails, but t0 and t1 get dumped to be
the same, is that C allows the implementation to use larger-than-64-bit
(for 64-bit) intermediate double representations. In the case of X86,
the CPU's floating-point registers are 80 bits wide.
When they get written to stack, the value is rounded (or truncated?) to
64 bits.
I don't understand why they just didn't write:
double t0, t1;
t0 = t1 = get_time();
Not everything *has* to be initialized at declaration time.
In the optimized code, I'll bet you that the two locals (t0 and t1) are
kept entirely in registers, at least until the t0 and t1 calls. So
at the point of comparison, it's comparing two 80-bit values, but when
you flush them to memory to dump them as integer values, they get
truncated to the (same) 64-bit value.
Possible. Consider SSE ops (64-bit vs 80-bit on x87) and use of
fast-math as well.
-cl
--
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: xargs problem
On Mon, Feb 19, 2007 at 01:28:17PM -0800, Christopher Layne wrote: Absolutely. I don't disagree with this. The issue is the magnitude. The opteron box has 4gigs of ram, scsi 320 disks, and is running water cooled at 2.8 ghz. Nothing *normal* can explain such a reason why a Celeron-D can fork the same /bin/echo's 15 times faster than that box, except for the OS difference. Even then, the difference is insane. 70 288 [main] xargs 5956 child_copy: dll data - hp 0x6C8 low 0x61118000, high 0x6111D040, res 1 75657 75945 [main] xargs 5956 child_copy: dll bss - hp 0x6C8 low 0x61175000, high 0x6117EC30, res 1 ^ 903 76848 [main] xargs 5956 child_copy: user heap - hp 0x6C8 low 0xA2, high 0xA4, res 1 | 44 76892 [main] xargs 5956 child_copy: done | 44 76936 [main] xargs 5956 child_copy: data - hp 0x6C8 low 0x406000, high 0x406050, res 1 | 29 76965 [main] xargs 5956 child_copy: bss - hp 0x6C8 low 0x409000, high 0x4093A0, res 1 | 21 76986 [main] xargs 5956 child_copy: done | |__ not normal And the plot thickens. http://www.sourceware.org/ml/cygwin/2006-12/msg00494.html http://www.sourceware.org/ml/cygwin/2006-12/msg00711.html -cl -- 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: screen
On Fri, Feb 16, 2007 at 04:14:06PM -0500, Christopher Faylor wrote: On Fri, Feb 16, 2007 at 01:01:23PM -0500, Andrew Schulman wrote: And, just in case you're wondering if I am going to volunteer to help you track down problems - I'm not. So, maybe anyone who wants screen should volunteer to help. No, that was not my intention. I was trying to be courteous. But that's a two-way street. Forget it, I won't bother next time. Since you were pinging me and since (on rereading) you were consistently asking for help, I don't think it was a huge leap for me to surmise that you might be wanting my help debugging problems. By stating my intentions, I wanted to make it clear that someone else needs to step in. cgf You know this kind of things just shuts people off and turns them away right? People are trying to make progress, trying to make things better, and they're basically being told to go away. If he could do it himself, I'm sure he would have solved the issue by now. If he can't, perhaps he needs the help. I don't see what's so groundbreaking about I'm not going to be able to help you with it now as I'm too busy, but perhaps throw the idea out there along with your observations and see who else bites. Is that somehow worse than Look, I don't have the time to help you track down problems, find someone else. ? -cl -- 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: Eliminating -mno-cygwin from gcc?
On Wed, Jan 31, 2007 at 08:13:37AM -0500, Christopher Faylor wrote: When I was maintaining cygwin's gcc, I often thought about eliminating -mno-cygwin and just providing a pure mingw cross compiler in the distribution. I really don't know why it wasn't done that way to begin with. I have vague recollections of arguing for this when -mno-cygwin was first introduced by Geoff Noer but apparently I wasn't very persuasive. I know that this will probably be another Death of Cygwin predicted Fine by me. Can we slip in removing text mounts at the same time? ;) -cl -- 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/
console + ctrl-c + gdb and all that
So exactly why was tty handling changed to ignore ctrl-c in some instances? I.e. if one is in gdb and I send a ctrl-c, it goes nowhere. Why is this? It worked at one time. And no, I'm not going to use the windows console to debug things. -cl -- 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: Newly-installed bash 3.2.9-10 (cygwin 1.5.24-1) exits when I try to execute a program
On Mon, Jan 29, 2007 at 07:31:37AM +0100, Christian Jullien wrote: I installed a new version of cygwin yesterday, and find that bash starts up and builtins seem to execute, but when I try the first command, cygwin exits This is not related to the new bash version but related to new cygwin 1.5.24-1. As soon I installed this new version alone without bash or any other cygwin package, my Windows X64 stopped to work for any cygwin command even if I run gcc from cmd.exe. Reverting to 1.5.23 let my system work again. Start Menu-Find-cygwin1.dll -cl -- 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: Antwort: Re: Error getpeername: Operation not permitted...
On Wed, Jan 24, 2007 at 03:42:51PM +0100, Corinna Vinschen wrote: What else could be the reason? Hmm, good question. I have a stock 2K3 Server installation running ssh just fine. Probably you will have to look outside of Cygwin. Do you have any personal firewall or virus scanner installed? See the mailing list archives and look for stuff like Agnitum Outpost, McAfee. W2K3E here too, never seen this error with sshd before. Some kind of funky privledge separation issue? -cl -- 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: ln -s exe magic (coreutils 6.7-2)
On Tue, Jan 23, 2007 at 06:07:17PM -0500, Pierre A. Humblet wrote: /usr/sbin: ls -l sendmail* lrwxrwxrwx 1 p-humblet sw 13 Jan 23 17:40 sendmail - /usr/bin/exim* lrwxrwxrwx 1 p-humblet sw 19 Jan 23 17:29 sendmail.exe - /usr/sbin/ssmtp.exe* so that the commands sendmail and sendmail.exe produce different results, cron keeps using exim and if exim is uninstalled then cron misbehaves. My suggestion is that by default ln -s should not do any magic. If some magic is desired, users can define an alias or shell function that adds --enable-exe-magic Pierre Probably just an oversight (in regards to symlinks) in the code handling .exe vs extentionless executables. It's there to allow both options for an executable to be named. I'm sure Corinna or Christopher will know what the deal is. -cl -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin source question
On Mon, Jan 22, 2007 at 10:42:19AM -, Dave Korn wrote: ... so no reason not to choose whichever you like the best. cheers, DaveK I prefer the idiom that doesn't resemble perl :). Also, if it were me, I'd just be checking for zero or non-zero. The rest seems like a lot of hoop jumping for not much gain. -cl -- 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/
cygwin source question
I notice in some places, there are double-negates, like: me-read_ready |= ret || !!(events (FD_READ | FD_ACCEPT | FD_CLOSE)); What's the rationale for these? To enforce either a 0 or 1, to be directly in line with boolean, rather than a zero or non-zero result? -cl -- 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/
cygexec strangeness
Kind of strange.
Am I missing something on how cygexec is supposed to be used?
$ cat o.c
#include stdio.h
#include sys/stat.h
#include fcntl.h
int main(int argc, char **argv)
{
int r;
if ((r = open(argv[1], O_RDONLY)) 0)
perror(open);
return 0;
}
$ gcc -g3 -ansi -pedantic -o o o.c
$ ./o o.c
$ mount -f -b -s -X 'c:\cygwin' /
$ ./o o.c
$ strace ./o o.c
strace: error creating process o, (error 2)
strace: error creating process o, (error 2)
strace: error creating process o, (error 2)
strace: error creating process o, (error 2)
strace: error creating process o, (error 2)
strace: error creating process o, (error 2)
I don't get that, but I'll presume it's intertwined with what
I'm asking about.
$ PATH=/var/tmp:$PATH strace o o.c
[...]
56 54874 [main] o 19080 open: open (o.c, 0x0)
35 54909 [main] o 19080 normalize_posix_path: src o.c
23 54932 [main] o 19080 cwdstuff::get: posix /c/WINDOWS/system32
22 54954 [main] o 19080 cwdstuff::get: (/c/WINDOWS/system32) =
cwdstuff::get (0x22C8A0, 260, 1, 0), errno 0
21 54975 [main] o 19080 normalize_posix_path: /c/WINDOWS/system32/o.c =
normalize_posix_path (o.c)
23 54998 [main] o 19080 mount_info::conv_to_win32_path: conv_to_win32_path
(/c/WINDOWS/system32/o.c)
23 55021 [main] o 19080 mount_info::cygdrive_win32_path: src
'/c/WINDOWS/system32/o.c', dst 'c:\WINDOWS\system32\o.c'
21 55042 [main] o 19080 set_flags: flags: binary (0x2)
83 55125 [main] o 19080 mount_info::conv_to_win32_path: src_path
/c/WINDOWS/system32/o.c, dst c:\WINDOWS\system32\o.c, flags 0x2A, rc 0
137 55262 [main] o 19080 symlink_info::check: GetFileAttributes
(c:\WINDOWS\system32\o.c) failed
25 55287 [main] o 19080 geterrno_from_win_error: windows error 2 == errno 2
51 55338 [main] o 19080 symlink_info::check: GetFileAttributes
(c:\WINDOWS\system32\o.c.lnk) failed
24 55362 [main] o 19080 geterrno_from_win_error: windows error 2 == errno 2
22 55384 [main] o 19080 symlink_info::check: 0 = symlink.check
(c:\WINDOWS\system32\o.c, 0x22C560) (0x2A)
21 55405 [main] o 19080 mount_info::conv_to_win32_path: conv_to_win32_path
(/c/WINDOWS/system32)
20 55425 [main] o 19080 mount_info::cygdrive_win32_path: src
'/c/WINDOWS/system32', dst 'c:\WINDOWS\system32'
20 55445 [main] o 19080 set_flags: flags: binary (0x2)
20 55465 [main] o 19080 mount_info::conv_to_win32_path: src_path
/c/WINDOWS/system32, dst c:\WINDOWS\system32, flags 0x2A, rc 0
39 55504 [main] o 19080 symlink_info::check: not a symlink
22 55526 [main] o 19080 symlink_info::check: 0 = symlink.check
(c:\WINDOWS\system32, 0x22C560) (0x2A)
72 55598 [main] o 19080 path_conv::check:
this-path(c:\WINDOWS\system32\o.c), has_acls(1)
31 55629 [main] o 19080 build_fh_pc: fh 0x611B2E08
58 55687 [main] o 19080 fhandler_base::open: (c:\WINDOWS\system32\o.c,
0x10)
62 55749 [main] o 19080 seterrno_from_win_error:
/netrel/src/cygwin-snapshot-20070110-1/winsup/cygwin/fhandler.cc:710 windows
error 2
24 55773 [main] o 19080 geterrno_from_win_error: windows error 2 == errno 2
20 55793 [main] o 19080 __set_errno: void seterrno_from_win_error(const
char*, int, DWORD):310 val 2
19 55812 [main] o 19080 fhandler_base::open: C034 = NtCreateFile (0x0,
8010, c:\WINDOWS\system32\o.c, io, NULL, 0, 7, 1, 4020, NULL, 0)
20 55832 [main] o 19080 fhandler_base::open: 0 = fhandler_base::open
(c:\WINDOWS\system32\o.c, 0x10)
17 55849 [main] o 19080 fhandler_base::open_fs: 0 =
fhandler_disk_file::open (c:\WINDOWS\system32\o.c, 0x0)
18 55867 [main] o 19080 open: -1 = open (o.c, 0x0)
[...]
What's the obsession with c/w/system32 ?
$ PATH=/var/tmp:$PATH strace o /var/tmp/o.c
43 34889 [main] o 52328 fhandler_base::open: (c:\cygwin\var\tmp\o.c,
0x10)
38 34927 [main] o 52328 fhandler_base::set_flags: flags 0x10,
supplied_bin 0x1
19 34946 [main] o 52328 fhandler_base::set_flags: filemode set to binary
16 34962 [main] o 52328 fhandler_base::open: 0 = NtCreateFile (0x6F0,
8010, c:\cygwin\var\tmp\o.c, io, NULL, 0, 7, 1, 4020, NULL, 0)
18 34980 [main] o 52328 fhandler_base::open: 1 = fhandler_base::open
(c:\cygwin\var\tmp\o.c, 0x10)
17 34997 [main] o 52328 fhandler_base::open_fs: 1 =
fhandler_disk_file::open (c:\cygwin\var\tmp\o.c, 0x0)
16 35013 [main] o 52328 open: 3 = open (/var/tmp/o.c, 0x0)
Hmmm...
$ mount -f -b -s 'c:\cygwin' /
$ strace ./o o.c
36 41956 [main] o 37300 fhandler_base::open: (c:\cygwin\var\tmp\o.c,
0x10)
36 41992 [main] o 37300 fhandler_base::set_flags: flags 0x10,
supplied_bin 0x1
18 42010 [main] o 37300 fhandler_base::set_flags: filemode set to binary
16 42026 [main] o 37300 fhandler_base::open: 0 = NtCreateFile (0x6F0,
8010, c:\cygwin\var\tmp\o.c, io, NULL, 0, 7, 1, 4020, NULL, 0)
17 42043 [main] o 37300 fhandler_base::open: 1 = fhandler_base::open
Re: cygexec strangeness
$ mount -f -b -s -X 'c:\cygwin' / $ strace ./o o.c 55 57473 [main] o 2656 fhandler_base::open: (c:\cygwin\var\tmp\o.c, 0x10) 87 57560 [main] o 2656 fhandler_base::set_flags: flags 0x10, supplied_bin 0x1 45 57605 [main] o 2656 fhandler_base::set_flags: filemode set to binary 38 57643 [main] o 2656 fhandler_base::open: 0 = NtCreateFile (0x6F4, 8010, c:\cygwin\var\tmp\o.c, io, NULL, 0, 7, 1, 4020, NULL, 0) 43 57686 [main] o 2656 fhandler_base::open: 1 = fhandler_base::open (c:\cygwin\var\tmp\o.c, 0x10) 40 57726 [main] o 2656 fhandler_base::open_fs: 1 = fhandler_disk_file::open (c:\cygwin\var\tmp\o.c, 0x0) 39 57765 [main] o 2656 open: 3 = open (o.c, 0x0) On Sat, Jan 20, 2007 at 01:44:53PM +0100, Corinna Vinschen wrote: On Jan 20 03:27, Christopher Layne wrote: Kind of strange. Am I missing something on how cygexec is supposed to be used? That's with a snapshot? If so, try the latest one. WJFFM. This works now. Strange. Was running 20070110. Just went to 20070118. -cl -- 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: 1.7.0 CVS mmap failure
On Thu, Jan 18, 2007 at 06:18:52PM +0100, Corinna Vinschen wrote: Right, it's an optimization problem rather than a bug. Patches welcome, but I've put it on my TODO list, too. I have applied a patch to CVS which calls fstat early, at the spot where GetFileSize got called so far. The stat structure is then propagated to subsequent function calls and used there. This should reduce the fstat calls to exactly one per file based mmap call. All my testcases still work fine, but we already saw that my testcases don't cover all weird cases in the world. So, please give this change a serious test. Thanks for fixing this. I also noticed these when reading through the code. Another area for extremely small optimization is to just cache the pagesize. I notice a *lot* of calls to getpagesize(), when I can't really see the pagesize changing within a single call to mmap(). Since the map implementations appear to use a data object for tracking/management, it should be pretty easy to add a psz size_t/DWORD/whatever to it. -cl -- 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: Snapshot speed on managing files
On Sat, Jan 13, 2007 at 09:02:03PM -, Dave Korn wrote: So, what's up on the slow machines? How full are your respective recycle bins? I've noticed just through deleting things in ordinary windows explorer that the recycle bin thrashes like crazy when it starts to get full; seriously thrashes, like 15 or 20 seconds just to delete a small file. cheers, DaveK Do you use power management or shut down your HDs automatically? I've noticed windows insists on spooling up all HDs upon even deleting a single file from the RB. -cl -- 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: Snapshot speed on managing files
On Thu, Jan 18, 2007 at 04:55:33PM +0100, Marco atzeri wrote: --- Marco atzeri [EMAIL PROTECTED] ha scritto: --- Larry Hall (Cygwin) Did you update your build recently? Corinna checked in a fix for this on Saturday http://cygwin.com/ml/cygwin-cvs/2007-q1/msg00021.html. I will wait the next snapshot to test the changes. 20070118 solved the issue. The timing now is acceptable If you have a moment, would it be possible for you to test your testcase on 20060309? I know this is going to send ridiculous, but if you have a moment I'm curious what your results are. -cl -- 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: 1.7.0 CVS mmap failure
On Thu, Jan 11, 2007 at 10:46:48AM +0100, Corinna Vinschen wrote: This works on my machine now. So previously why was the former method failing, do you think? Er... haven't we discussed this at great lengths in this thread? Yes, but did we ever establish a reason that was actually solid in foundation? The reason I ask again what may be obvious is because of the still-present ambiguity back here: That's not visible in the above strace. Since the pagesize is supposed to be == allocation granularity == 64K, but file mappings are aligned to the next page boundary beyond EOF (sigh), Cygwin tries to accomodate the expectations of the application by appending an anonymous mapping to fill the whole mapping up to 64K. In the failing case this should still work, since 0x7fff7000 + 0x9000 (36864 dec) == 0x8000, so the mapping should fit into the usual 2 Gig address space. Why Windows fails to do it, I have no idea. The error code 487 means invalid address which might mean already taken address, but that's not visible in the strace. To figure that out would require to add a bit of VirtualQuery code to mmap and add appropriate debug output. Actually this shows a problem in the mmap implementation with respect to MEM_TOP_DOWN. I think, what mmap should actually do is to create a lightweight MAP_RESERVE anonymous mapping of the whole requested mapping size, then close it again and then reopen it with the address it got in this first try. This would probably ensure that the subsequent two mapping will work. However, it's not quite clear if that really would help since the above *should* have worked to the best of my knowledge. Corinna The real question I have is why was what *should* have worked, not working? -cl -- 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: 1.7.0 CVS mmap failure
On Sat, Jan 13, 2007 at 11:25:08AM +0100, Corinna Vinschen wrote: On Jan 13 00:22, Christopher Layne wrote: The real question I have is why was what *should* have worked, not working? That has been answered immediately in the replies: http://cygwin.com/ml/cygwin/2007-01/msg00093.html http://cygwin.com/ml/cygwin/2007-01/msg00095.html http://cygwin.com/ml/cygwin/2007-01/msg00097.html Also, thanks for working with us to fix it - it's appreciated. -cl -- 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: 1.7.0 CVS mmap failure
Since overmapping doesn't work on Windows, unfortunately, I implemented the above mentioned technique, which isn't much code anyway. It reserves a memory lot big enough to fit in the whole mapping, memorizes the address, free's the memory again and then uses the new address in the subsequent real mappings. This should work (knock on wood) on all systems now. My testcases still work on my 512 MB machine, so I'd appreciate if you could give the latest snapshot a try on /3GB enabled machines. This works on my machine now. So previously why was the former method failing, do you think? -cl -- 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: 1.7.0 CVS mmap failure
On Jan 10 09:37, Brian Ford wrote: Yes, this fixes my STC and the application from which it was derived. Thanks. BTW: a couple of things: 1. Is there a possibility of another application or thread reserving that just alloc/free'd area right after using it to obtain (at that time) a valid address? 2. What exactly is the difference between using CreateFileMapping and MapViewOfFile vs what we're doing now which seems to use NtMapViewOfSection? -cl -- 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: 1.7.0 CVS mmap failure
On Sun, Jan 07, 2007 at 11:58:44AM +0100, Corinna Vinschen wrote:
Lots of comments throughout the file...
Unfortunately the code-path is less than clear to follow. This may be
a matter of opinion but it's fairly complex and looks to have history in
it.
In the 2nd strace, I changed the mmap logic to stop trying to align the 1st
map on a 4k granularity boundary and just allocate a single map w/ 64k of
left over dead space (what I would typically expect in posix land). I also
added more debug info at various stages to try and figure things out. When
changing it to use 64k period, the mmaps are both successful - which is
good,
but VirtualProtect always fails, no matter what, on unmap.
The strace is rather useless without the (hopefully very short) source
code of the (hopefully very small) testcase.
Okay, I understand where you're coming from. Where I'm coming from is that it
is difficult to generate a test case that actually demonstrates the issue
outside of the scope of my application. Suffice to say, I do see the errors in
strace output - and I can see MapViewNT returning an error in the double-map
-so-we-can-have-4k-pseudopages version. Do you have a 4GB machine running w/
PAE enabled in which to even test a test case if I could come up with one which
consistently works? Also, VirtualProtect fails on unmap everytime, a test case
for this is a matter of any old map/unmap it seems.
33 /* Filler pages are the pages from the last file backed page to the next
3464K boundary. These pages are created as anonymous pages, but with
35the same page protection as the file's pages, since POSIX applications
36expect to be able to access this part the same way as the file pages. */
37 #define __PROT_FILLER 0x400
1247 if (orig_len)
1248 {
1249 /* If the requested length is bigger than the file size, the
1250 remainder is created as anonymous mapping. Actually two
1251 mappings are created, first the reminder from the file end to
1252 the next 64K boundary as accessible pages with the same
1253 protection as the file's pages, then as much pages as necessary
1254 to accomodate the requested length, but as reserved pages which
1255 raise a SIGBUS when trying to access them. AT_ROUND_TO_PAGE
1256 and page protection on shared pages is only supported by 32 bit
NT,
1257 so don't even try on 9x and in WOW64. This is accomplished by not
1258 setting orig_len on 9x and in WOW64 above. */
1259 orig_len = roundup2 (orig_len, pagesize);
1260 len = roundup2 (len, getsystempagesize ());
^
Why? This also violates the to the next 64k boundary as accessible pages part.
The pagesize is 64k, the granularity for addressing is 4k. Don't see why 4k has
to be mixed in here by calling getsystempagesize() or am I totally missing
something here?
1261
1262 if (orig_len - len)
1263 {
1264 orig_len -= len;
1265 size_t valid_page_len = orig_len % pagesize;
1266 size_t sigbus_page_len = orig_len - valid_page_len;
1267
1268 caddr_t at_base = base + len;
The system shall always zero-fill any partial page at the end of
an object. Further, the system shall never write out any
modified portions of the last page of an object which are beyond
its end. References within the address range starting at pa
and continuing for len bytes to whole pages following the end of an
object shall result in delivery of a SIGBUS signal.
Which I would expect to be: |0 len 65536| on Windows.
/* start */
#include fcntl.h
#include stdio.h
#include unistd.h
#include sys/mman.h
#include sys/stat.h
int main(int argc, char **argv)
{
struct stat st;
long psz, r;
char *q;
char a;
int fd;
if (argc = 2) return -1;
if ((fd = open(argv[1], O_RDONLY)) == -1) {
perror(open);
return -1;
}
if (fstat(fd, st) == -1) {
perror(stat);
return -1;
}
psz = sysconf(_SC_PAGESIZE);
fprintf(stderr, psz = %ld\n, psz);
fprintf(stderr, st.st_size == %lu\n, (long)st.st_size);
q = mmap(0, st.st_size, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
if (q == MAP_FAILED) {
perror(mmap);
return -1;
}
if (*argv[2] == 'r') {
for (r = 0; ; r++) {
if (r st.st_size)
fprintf(stderr, %lu , r);
a = q[r];
}
} else if (*argv[2] == 'w') {
for (r = 0; ; r++) {
if (r st.st_size)
fprintf(stderr, %lu , r);
q[r] = a;
}
}
return 0;
}
/* end */
Re: 1.7.0 CVS mmap failure
Also, check this out: http://blogs.msdn.com/oldnewthing/archive/2003/10/08/55239.aspx Meant to also include: http://support.microsoft.com/kb/125713 -- 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: 1.7.0 CVS mmap failure
Real quick here and I'll follow up tomorrow. I don't get SIGSEGV in my application ever. I get an error back from mmap saying it cannot allocate memory when i'm simply trying to open a small file! The original events ere posted up in that first part of the strace - which is unmodified original behavior. Things did not start happening UNTIL the MEM_TOP_DOWN change. My code does not do ANYTHING out of the ordinary that it wasn't doing before and working completely fine with. On Tue, Jan 09, 2007 at 12:56:43PM +0100, Corinna Vinschen wrote: Yet the latter works for me, whereas the former results in mmap() failures for files smaller than the page size. The latter works for you because it's wrong. Since it uses 64K, mmap thinks it doesn't have to add filler pages. So adding the filler pages can't go wrong. So you can access your file, but you get the SEGV exaclty after the last 4K page of the file, not at the end of the expected 64K page. Corinna -- 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: 1.7.0 CVS mmap failure
On Tue, Jan 09, 2007 at 01:23:58PM +0100, Corinna Vinschen wrote: Yes, I know. I never said you get a SEGV from mmap, but you get the SEGV in your testapp. That's what I'm referring to. mmap fails (just fails, no SEGV, yes, I know) because it fails to generate the filler pages. This should be really clear know from what I wrote. Sorry, I should have indicated that the test app was purely used to test out mapping regions and boundaries - not show off the original issue. I found certain things about the boundaries on windows to be peciluar. When I looked up what getpagesize() and getsystempagesize() return, respectively, I could have sworn that GPS returned page size and GSPS returned allocation granularity (both via GetSytemInfo). -cl -- 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: 1.7.0 CVS mmap failure
On Tue, Jan 09, 2007 at 12:56:43PM +0100, Corinna Vinschen wrote:
Okay, I understand where you're coming from. Where I'm coming from is that
it
is difficult to generate a test case that actually demonstrates the issue
outside of the scope of my application. Suffice to say, I do see the errors
in
strace output - and I can see MapViewNT returning an error in the double-map
-so-we-can-have-4k-pseudopages version.
I'm under the impression you're getting something upside-down. Windows
has 4K system pages, but an allocation granularity of 64K. For a long
time I stubbornly tried to stick with 4K pagesize for POSIX applications,
but the code got more and more complicated because there was always yet
another situation which just didn't work correctly due to the 64K
allocation granularity.
extern C size_t
getpagesize ()
{
if (!system_info.dwPageSize)
GetSystemInfo (system_info);
return (size_t) system_info.dwAllocationGranularity;
}
size_t
getsystempagesize ()
{
if (!system_info.dwAllocationGranularity)
GetSystemInfo (system_info);
return (size_t) system_info.dwPageSize;
}
Turns out I was reading these backwards, yes.
$ ./psz
psz == 4096, ag == 65536
I'll try and reanalyze some of the other stuff tomorrow.
-cl
--
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: 1.7.0 CVS mmap failure
(warning a bunch of strace, scroll wide). So I haven't been able to totally nail anything down on this issue due to the incredible complexity of Cygwin's mmap interface. This is 2 simple mmap()s in succession, 1st is 46121 bytes, 2nd is 111 bytes. Both opened read/write. The second mmap always fails. This is the current snapshot code. In the 2nd strace, I changed the mmap logic to stop trying to align the 1st map on a 4k granularity boundary and just allocate a single map w/ 64k of left over dead space (what I would typically expect in posix land). I also added more debug info at various stages to try and figure things out. When changing it to use 64k period, the mmaps are both successful - which is good, but VirtualProtect always fails, no matter what, on unmap. 1st strace 130 5635179 [unknown (0x22C0)] iswcs 14132 mmap64: fh == 1628914712, addr == 0x0, len == 46121, off == 0, prot == 0, flags == 3, fd == 1 29 5635208 [unknown (0x22C0)] iswcs 14132 CreateMappingNT: fhdl == 3442792, name == 0x611744B0, len == 46121, off == 0, prot == 0, flags == 3 43 5635251 [unknown (0x22C0)] iswcs 14132 CreateMappingNT: h == 3443708, name == 0x611744B0, len == 46121, off == 0, prot == 0, flags == 3 54 5635305 [unknown (0x22C0)] iswcs 14132 MapViewNT: 7FB4 = NtMapViewOfSection (h:348BFC, addr:0, len:46121, off:0, protect:40, type:0) 128 5635787 [unknown (0x22C0)] iswcs 14132 mmap64: fh == 1628914712, addr == 0x0, len == 49152, off == 0, prot == 0, flags == 3, fd == 1, orig_len == 12 29 5635816 [unknown (0x22C0)] iswcs 14132 mmap64: orig_len == 16384, len == 49152, pagesize == 65536, valid_page_len == 16384, sigbus_page_len == 0, at_base == 0x7FB4C000 30 5635846 [unknown (0x22C0)] iswcs 14132 CreateMappingNT: fhdl == 4294967295, name == 0x61174660, len == 16384, off == 0, prot == 0, flags == 67108867 33 5635879 [unknown (0x22C0)] iswcs 14132 CreateMappingNT: h == 3443812, name == 0x61174660, len == 16384, off == 0, prot == 0, flags == 67108867 49 5635928 [unknown (0x22C0)] iswcs 14132 MapViewNT: 7FB4C000 = NtMapViewOfSection (h:348C64, addr:7FB4C000, len:16384, off:0, protect:40, type:0) 55 5635983 [unknown (0x22C0)] iswcs 14132 mmap64: orig_len == 16384, len == 49152, pagesize == 65536, valid_page_len == 16384, sigbus_page_len == 0, at_base == 0x7FB5 2361 5638344 [unknown (0x22C0)] iswcs 14132 mmap_record::unmap_pages: addr == 0x7FB4C000, len == 65536, off == 0 43 5638387 [unknown (0x22C0)] iswcs 14132 mmap_record::unmap_pages: VirtualProtect in unmap_pages () failed, Attempt to access invalid address. 81 5638468 [unknown (0x22C0)] iswcs 14132 mmap_record::unmap_pages: addr == 0x7FB4, len == 65536, off == 0 30 5638498 [unknown (0x22C0)] iswcs 14132 mmap_record::unmap_pages: VirtualProtect in unmap_pages () failed, Attempt to access invalid address. 1198 5913621 [unknown (0x22C0)] iswcs 14132 mmap64: fh == 1628914712, addr == 0x0, len == 111, off == 0, prot == 0, flags == 3, fd == 1 111 5913732 [unknown (0x22C0)] iswcs 14132 CreateMappingNT: fhdl == 3443684, name == 0x611744B0, len == 111, off == 0, prot == 0, flags == 3 -1732 5913854 [unknown (0x22C0)] iswcs 14132 CreateMappingNT: h == 3442152, name == 0x611744B0, len == 111, off == 0, prot == 0, flags == 3 135 5917163 [unknown (0x22C0)] iswcs 14132 MapViewNT: 7FB5 = NtMapViewOfSection (h:3485E8, addr:0, len:111, off:0, protect:40, type:0) 1964 5954789 [unknown (0x22C0)] iswcs 14132 mmap64: fh == 1628914712, addr == 0x0, len == 4096, off == 0, prot == 0, flags == 3, fd == 1, orig_len == 38 581 5955463 [unknown (0x22C0)] iswcs 14132 mmap64: orig_len == 61440, len == 4096, pagesize == 65536, valid_page_len == 61440, sigbus_page_len == 0, at_base == 0x7FB51000 -2520 5965447 [unknown (0x22C0)] iswcs 14132 CreateMappingNT: fhdl == 4294967295, name == 0x61174660, len == 61440, off == 0, prot == 0, flags == 67108867 -1010 5968842 [unknown (0x22C0)] iswcs 14132 CreateMappingNT: h == 3443752, name == 0x61174660, len == 61440, off == 0, prot == 0, flags == 67108867 771 5973717 [unknown (0x22C0)] iswcs 14132 MapViewNT: 0 = NtMapViewOfSection (h:348C28, addr:7FB51000, len:61440, off:0, protect:40, type:0) 315 5976384 [unknown (0x22C0)] iswcs 14132 __set_errno: void* mmap64(void*, size_t, int, int, int, _off64_t):1283 val 12 2nd strace 429 6379631 [unknown (0x2164)] iswcs 24296 CreateMappingNT: fhdl == 3442760, name == 0x611744B0, len == 46121, off == 0, prot == 0, flags == 3 116 6379747 [unknown (0x2164)] iswcs 24296 CreateMappingNT: h == 3443780, name == 0x611744B0, len == 46121, off == 0, prot == 0, flags == 3 376 6380462 [unknown (0x2164)] iswcs 24296 MapViewNT: 7FB4 = NtMapViewOfSection (h:348C44, addr:0, len:46121, off:0, protect:40, type:0) -986 6405625 [unknown (0x2164)] iswcs 24296 mmap64: fh == 1628914712, base == 0x7FB4, addr == 0x0, len == 46121, orig_len == 46121, off == 0, prot == 0, flags == 3, fd == 1 -2321 6407688 [unknown (0x2164)]
Re: 1.7.0 CVS mmap failure
While this also passes on mine - mmap has been performing strangely for me also (since around November snapshots). SPECIFICALLY: After the allocate downwards change was done, mmap calls started returning ENOMEM (Cannot allocate memory) where they worked before just fine. I specifically noticed in only in one threaded application of mine but was unable to create a test case that could duplicate it - so I haven't really posted up the issue either. I will also say this, I only get ENOMEM if mmap() tries to map a file LESS than the system page size. That is what I can duplicate everytime. Once it rises above the pagesize, then mmap() has no issues. The actual manifestation of failure is MAP_FAILED returned from mmap(). While his test case may have passed for the both of us, there is definitely something funky going on with mmap() since the allocate downwards change was OR'd into the underlying VirtualAlloc() call. -cl On Fri, Jan 05, 2007 at 10:57:52AM +0100, Corinna Vinschen wrote: On Jan 4 17:17, Brian Ford wrote: $ uname -a CYGWIN_NT-5.1 PC1163-8460-XP 1.7.0(0.161/4/2) 2007-01-04 15:51 i686 unknown unknown Cygwin $ ./mmaptest.exe CloseHandle(fh_disk_file.get_handle ()) 0x738 failed void* mmap64(void*, size_t, int, int, int, _off64_t):1275, Win32 error 6 mmap: Cannot allocate memory STC attached. Thanks. Hmm, STCs are nice, but this STC works fine for me, reproducibly: $ ./mmaptest test passed Something's missing in the picture... -- 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: 1.7.0 CVS mmap failure
mmap() is supposed to zero-fill, not refuse to map when len is less than the system page size. I have never ever seen mmap() fail to map less than page size on any typical Posix system. The system shall always zero-fill any partial page at the end of an object. Further, the system shall never write out any modified portions of the last page of an object which are beyond its end.References within the address range starting at pa and continuing for len bytes to whole pages following the end of an object shall result in delivery of a SIGBUS signal. Back to the original issue, consider this: MEM_TOP_DOWN 0x10Allocates memory at the highest possible address. If there were any kind of simple arithmetic bug behind mmap()'s scenes (such as computing space to zero-fill, etc. etc.) I would think ENOMEM would be a very common scenario if we're allocating near the end of addressible space. -cl On Fri, Jan 05, 2007 at 05:06:50PM +0100, Samuel Thibault wrote: Not sure about the cygwin state, but at least on the Linux/Posix side, mmap() is not supposed to be able to work with a smaller granularity than a memory page. Samuel -- 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: 1.7.0 CVS mmap failure
On Fri, Jan 05, 2007 at 10:17:19AM -0600, Brian Ford wrote: Ok, after further investigation, this is a /3GB boot.ini flag interaction. Unfortunately, this is a critical flag for our application, so all our machines are configured this way. That is why I failed to realize its significance before. I should also note that my system is a 4GB W2003 box w/ PAE enabled (no /3GB switch though). 4GB is available to the OS as well (give or take a small bit). I understand if this is now too much of an obscure case for you to be interested in. If so, I'll try to look into it soon on my own. I suspect it must have been related to your MEM_TOP_DOWN change. Yep. Never had a problem before it. -cl -- 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: 1.7.0 CVS mmap failure
On Fri, Jan 05, 2007 at 11:34:36AM -0500, Christopher Faylor wrote: MEM_TOP_DOWN 0x10 Allocates memory at the highest possible address. If there were any kind of simple arithmetic bug behind mmap()'s scenes (such as computing space to zero-fill, etc. etc.) I would think ENOMEM would be a very common scenario if we're allocating near the end of addressible space. % grep simple arithmetic bug mmap.cc % Seems fine to me. It's probably a hyperthreaded, dual-core problem. cgf Right, like the mental bash bug I brought up ages ago... Anyways, I interpret the grep blah answer as a figure it out. I was throwing out the thoughts to get people moving in parallel on figuring it out. I can't look into it right now - but was prompted to add my thoughts since I noticed someone else noticed. I can tell you this, it's not a machine issue. Something is amiss since the top down change. I don't have the answer right now as to what it is and won't be able to debug on my own for a bit (work). -cl -- 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/
simply cygwin1.dll
May seem sort of newbish, but I just noticed that one cannot move cygwin1.dll into place after removing the old one. For instance, if I download a snapshot to some tmp directory, exit all cygwin related apps and use explorer to move the new dll from the tmp to c:\cygwin\bin - I'll get the standard crop of bad dll related failures. However if I *copy* the file (ctrl-drag) things work fine. I presume this is some kind of windows dll manipulation thing or is it just my system? -cl -- 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: bash-3.1-7 BUG
On Wed, Sep 13, 2006 at 08:19:02PM -0400, Christopher Faylor wrote: As long as you have Corinna or myself in charge we are going to stick with the whole Linux on Windows thing. If bash doesn't like \r\n line endings on Linux, if we purposely recommend against using text mode files, and if we can see noticeable performance improvements in bash from not honoring \r\n line endings, then bash should definitely be using the binmode code. Yep. Ridiculous performance improvements at that. If Eric cares enough to make \r\n shell scripts work in bash, then more power to him. If he doesn't then I have no problem with releasing a bash that hiccups on files which use \r\n and informing people that they should fix their scripts. cgf Totally agreed here too. I've been using my splintered off bash build for weeks now. Haven't really had any issues - however I also explicitly do not use text mode mounts or any related nonsense. -cl -- 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: bash-3.1-7 BUG
I suspect that the Well, they can just install Linux (floppies, CDs, DVDs) if they feel like it observation has been made several times a year for the last ten years. It's obviously not a very powerful argument since Cygwin is still here and you can't really assert that the only reason it is here is because make understood MS-DOS paths or bash dealt properly with \r\n line endings. I personally use Cygwin to make full use of a unix shell and environ along side windows - typically with around 8-10 puttycygs open along with NX clients to Linux machines running NX. Since it's inevitable that windows will creep into things, there's not much one can do to get around it - aside from making a personal pact 'not going to use windows' - which we've all most likely done and eventually failed out. That being said, if I didn't require just a few windows applications that I use aside from Cygwin, I'd be running KDE/Linux 2.6 on this box in a heartbeat. That being said, I think cygwin is great, and I find it invaluable under windows. I really couldn't imagine using MSW without cygwin. I doubt that Eric will want to deal with the fallout of having bash not understand \r\n line endings but, if he does, it would be his decision and, again, I would support it 100%. I am very eager to see things like configure scripts work faster and if we have to drop a few scared or lazy people along the way to accomplish that goal, that's fine with me. I have no problem at all with being a part of a smaller community which doesn't need to use notepad to edit their bash scripts. Yep - and what section of the bell curve do people who write in bash/sh *on* cygwin *also* use notepad to edit the files? I would think 95% are using vi/vim. -cl -- 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: bash-3.1-7 BUG
On Thu, Sep 14, 2006 at 12:58:36PM -0400, Volker Quetschke wrote: +#ifdef __CYGWIN__ + /* lseek'ing on text files is problematic; lseek reports the true + file offset, but read collapses \r\n and returns a character + count. We cannot reliably seek backwards if nr is smaller than + the seek offset encountered during the read, and must instead + treat the stream as unbuffered. */ + if ((bp-b_flag (B_TEXT | B_UNBUFF)) == B_TEXT) ^ ^^ part of the patch looks suspicious to me. You probably just want to test if the LHS expression is true. Volker It's called a mask. -cl -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Updated [experimental]: bash-3.1-8
On Thu, Sep 14, 2006 at 03:00:27PM +0100, Dave Korn wrote: On 14 September 2006 14:17, Wells, Roger K. wrote: Thank you. You made me realize that I could modify .inputrc to cause Ctrl-l to execute my version of clear which does what I want. Now if I could do it in Linux... echo -e \033c might work if clear doesn't. Good ole ANSI codes. We'll all be dead in our graves before ANSI escape codes fall out of use/support. ;) -cl -- 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: simply cygwin1.dll
On Wed, Sep 20, 2006 at 11:31:09PM -0400, Larry Hall (Cygwin) wrote: Hard to say without seeing what you're seeing (insert standard plug for http://cygwin.com/problems.html here ;-) ). The standard problem when doing what you're doing is forgetting to stop services. Other than that, your basic description fits my modus-operandi for replacing the DLL manually. So perhaps it is just your system. ;-) One would think it were something typical like that. But I explicitly issued a 'net stop sshd', 'net stop syslogd' and had task manager up verifying every single cygwin related process was absolutely dead. It wasn't until I moved the new snapshot dll out of c:\cygwin\bin and then literally copied it back into the same directory that things worked as they normally should. Previous to that I had just dragged (moved) the latest snapshot dll from c:\cygwin\var\tmp\cygsnap to c:\cygwin\bin after moving the old one out of the way (at this point all cygwin related processes were dead). I wonder if it's a result of me renaming the new snapshot dll to cygwin1.dll right before I exited my final cygwin shell. I would think windows wouldn't even know that file was there yet (just sitting in some temp directory). But I also know very little about window's behind the scenes dll behavior. -cl -- 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: gdb attach to process to produce stacktrace
On Wed, Sep 20, 2006 at 03:17:29PM -0400, Ethan Tira-Thompson wrote:
For a quick example, try figuring out why this example program is
crashing... The idea is simple: set up an array of strings containing
'a' through 'z', build a string from 100 random selections, and then
display the result.
No fair figuring it out from looking at the code (it's a suitably
subtle newbie type problem, though obfuscated enough it's not
glaringly obvious) -- pretend it's a real problem in a piece of
fairly complicated code that isn't just a dozen lines long, try using
gdb to figure it out. (for the lazy/hurried, answer posted here,
including comparison to what happens in cygwin: http://ethan.tira-
thompson.com/stuff/gdb-answer.html )
Had to admit to pull up the test case in a debugger because Ethan
was right, it wasn't obvious ;). Anyways, my method of dealing with
the immediate segfault type situation is to pull it up in gdb and
hope for a violation that will give me a useful backtrace. If that
doesn't occur, I just do a general 'b main' and next until I step
over the function that causes it and then do the same thing within
the violating function. In this case it was easy - since I recognized:
37619 [main] whack 2976 _cygtls::handle_exceptions: Exception:
STATUS_ACCESS_VIOLATION
38212 [main] whack 2976 open_stackdumpfile: Dumping stack trace to
whack.exe.stackdump
as being a typical buffer walk off *and* the fact that it wasn't a
large amount of iterations (which is really what made things to be
easy - otherwise it's serious pain).
int initStrs(char* strs[]) {
// initialize a string for each letter^M
int i;
for(i=0; i'z'-'a'; i++) {^M
strs[i]=malloc(sizeof(char[2]));^M
strs[i][0]='a'+i; // current letter^M
strs[i][1]='\0'; // null terminate for a c-style string^M
}
return 26;
}
Culprit:
(gdb) p 'z' - 'a'
$16 = 25
--
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: downgrading make version
On Thu, Sep 21, 2006 at 12:57:58AM -0400, Christopher Faylor wrote: (CP) = \cp install: $(PROGS) $(CP) $(PROGS) $(INSTBINDIR) \cp nda.exe mtk.exe sda.exe /home/mast/CYGMOD/bin make: \cp: Command not found The above is not valid makefile syntax but if I make obvious corrections, I get the same thing on Linux. I don't know what you were expecting \cp to be translated to, but it shouldn't, IMO, be interpreted as a MS-DOS path. Within a shell, one may also use \command to override an alias. Either way, Makefile isn't a shell so it's bogus there. -cl -- 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/
