Re: ls and wildcards
Am 14.07.2009, 17:47 Uhr, schrieb Christopher Faylor : Btw, some versions of cmd.exe don't work well with executables which lack extensions. I just ran into this problem recently. I don't remember exactly where, probably it was with NT 4. Perhaps Cygwin 1.7 should do away with NT compatibility and require Win2k. While NT is much closer to the pack than the DOS 7 video game that Win 9X/ME used to be, NT4 has been out of extended support for five years now. While Cygwin certainly doesn't want to bully people into upgrading their costly M$ installations, I think it's useful to do that if it saves work the Cygwin maintainers. -- Matthias Andree -- 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] Bug in link() with long filenames
Corinna Vinschen wrote: > I changed the internal fhandler_base::fstat_by_handle method not to > use the FileAllInformation info class at all, since we don't need the > filename anyway in stat. > > Thanks for the report, Thanks for the fix. Confirmed that it fixes the test case on my system. -- Chuck -- 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: ls and wildcards
On Jul 15 09:34, Matthias Andree wrote: > Am 14.07.2009, 17:47 Uhr, schrieb Christopher Faylor > : > >> Btw, some versions of cmd.exe don't work well with executables which lack >> extensions. I just ran into this problem recently. I don't remember >> exactly where, probably it was with NT 4. > > Perhaps Cygwin 1.7 should do away with NT compatibility and require Win2k. It's not an NT4 problem. cmd and Windows Explorer behave like this: http://cygwin.com/ml/cygwin/2009-07/msg00460.html (last paragraph) on all Windows systems. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [1.7] bug in chdir
On Jul 14 21:47, Eric Blake wrote:
> $ ls //home
> ls: reading directory //home: No such file or directory
> $ # makes sense; I don't have a remote machine named home
> $ cd //home
> $ # huh? no error reported?
> $ /bin/pwd # avoid shortcuts in bash builtin; /bin/pwd uses getcwd
> //home
Sorry Eric, but I can't reproduce this. I tried it on XP and 2K8R2
with identical result.
That's what I get in bash:
cori...@cathi ~
$ ls //home
ls: cannot access //home: No such file or directory
cori...@cathi ~
$ cd //home
bash: cd: //home: No such file or directory
cori...@cathi ~
$
And that's what I get in dash:
$ ls //home
ls: cannot access //home: No such file or directory
$ cd //home
cd: 2: can't cd to //home
$
> $ dash -c 'CDPATH=/; cd home'
> //home
On my systems this result in:
$ dash -c 'CDPATH=/; cd home'
cd: 1: can't cd to home
I also tried a simple test application which removes the shell
magic from the picture:
#include
int
main (int argc, char **argv)
{
int ret = 0;
if (argc > 1)
ret = chdir (argv[1]);
if (ret)
perror ("chdir");
return 0;
}
$ gcc -g -o chdir chdir.c
$ ./chdir //home
chdir: No such file or directory
$
If you're able to cd to //home, then there must be some crucial
difference in your environment. You should debug this, at least with
strace, so we can find out under what circumstances this occurs.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: .#* lock files under X, for files I edit???
Marc Girod wrote: > > Thanks. I'll try that. > That was: 'CYGWIN=winsymlinks tty' The result is not fully satisfying. E.g.: lrwxrwxrwx 1 emagiro EEI-ATusers45 Jul 14 11:57 .#common.mk -> emag...@ev0016d4a35054.eemea.ericsson.se.4708 in a dired buffer, and which I cannot remove: makesystem> rm -f .\#* rm: cannot remove `.#common.mk': Permission denied The process is still running indeed, but the lock/link doesn't go away when I kill the buffer, or even exit emacs, as shown with this one (elsewhere): bin> ls -la .#select_config.pl lrwxrwxrwx 1 emagiro EEI-ATusers 45 Jun 26 16:09 .#select_config.pl -> emag...@ev0016d4a35054.eemea.ericsson.se.4620 This process has gone long ago! The reason is the same I guess as the one for which I cannot remove the link from the command line, and has to do either with the fact the file system is CIFS mounted from a NetApp filer, or with the fact this is not its real name. I can access this filesystem from unix as well, and there, it looks different, and I can remove it: makesystem> ll .\#* -r-xr-xr-x 1 emagiro at1 299 Jul 14 11:57 .#common.mk.lnk makesystem> rm -f .\#* makesystem> ll .\#* .#*: No such file or directory Gone now from the cygwin view as well. But I understand this is the *old* symlink implementation, as a file with a funny name, instead of as a reall sym link, incurring the performance penalties, etc. So, my next move now will be to set a find-file-hook to check whether I am in a ClearCase view, and if so, to make purify_flag buffer-local and set it to t. I'll report my results... Marc -- View this message in context: http://www.nabble.com/.-*-lock-files-under-X%2C-for-files-I-edittp23655794p24494476.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: .#* lock files under X, for files I edit???
Marc Girod wrote: > > I'll report my results... > Here is what I did, to make it practical: (defun clearcase-no-lock() "Under ClearCase, in Cygwin, do not create lock symlinks. Either format (old: Windows shortcuts; new: real symlinks with utf name) are bad for different reasons. The only way to prevent this is to set the purify_flag used by emacs while dumping... This function is intened as a find-file-hook." (let ((fname (buffer-file-name))) (if (file-accessible-directory-p (concat fname "@@")) (set (make-local-variable 'purify_flag) t (add-hook 'find-file-hook 'clearcase-no-lock) Note that this would work only for 'elements' (i.e. not for view private files) since their version tree opens as a directory under the '@@' filename extension. I guess it is a faster check than invoking cleartool... Marc -- View this message in context: http://www.nabble.com/.-*-lock-files-under-X%2C-for-files-I-edittp23655794p24495013.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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] bug in chdir
Could it be that a mount point called /home, or //home (if possible), makes a
difference?
- Original Message -
From: cygwin-ow...@cygwin.com
To: cygwin@cygwin.com
Sent: Wed Jul 15 04:46:35 2009
Subject: Re: [1.7] bug in chdir
On Jul 14 21:47, Eric Blake wrote:
> $ ls //home
> ls: reading directory //home: No such file or directory
> $ # makes sense; I don't have a remote machine named home
> $ cd //home
> $ # huh? no error reported?
> $ /bin/pwd # avoid shortcuts in bash builtin; /bin/pwd uses getcwd
> //home
Sorry Eric, but I can't reproduce this. I tried it on XP and 2K8R2
with identical result.
That's what I get in bash:
cori...@cathi ~
$ ls //home
ls: cannot access //home: No such file or directory
cori...@cathi ~
$ cd //home
bash: cd: //home: No such file or directory
cori...@cathi ~
$
And that's what I get in dash:
$ ls //home
ls: cannot access //home: No such file or directory
$ cd //home
cd: 2: can't cd to //home
$
> $ dash -c 'CDPATH=/; cd home'
> //home
On my systems this result in:
$ dash -c 'CDPATH=/; cd home'
cd: 1: can't cd to home
I also tried a simple test application which removes the shell
magic from the picture:
#include
int
main (int argc, char **argv)
{
int ret = 0;
if (argc > 1)
ret = chdir (argv[1]);
if (ret)
perror ("chdir");
return 0;
}
$ gcc -g -o chdir chdir.c
$ ./chdir //home
chdir: No such file or directory
$
If you're able to cd to //home, then there must be some crucial
difference in your environment. You should debug this, at least with
strace, so we can find out under what circumstances this occurs.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gold star requests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Christopher Faylor on 7/14/2009 9:38 AM: >> While we're at it, I'd like to add a gold star for Dave Korn, for his >> persistence to fix the Cygwin problems which turned up by working on >> the new gcc 4 libstdc++ and libgfortran problems. > > Yes, good point. Big ditto. And look how long it's been since Corinna earned a star - doesn't she deserve one for her tireless efforts in long file name and wide character implementation? - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpdwJEACgkQ84KuGfSFAYDvvwCfQA0OB+ebnqp99KkhZ++EHwmC F6cAn0gCpgPXiolv9gDztw9+YNfkNX+S =tfO7 -END PGP SIGNATURE- -- 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: gold star requests
> And look how long it's been since Corinna earned a star - doesn't she > deserve one for her tireless efforts in long file name and wide character > implementation? Big +1 from me on that one! Chris -- Chris Sutcliffe http://emergedesktop.org -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [1.7] bug in chdir
On Jul 15 07:23, Ashok Vadekar wrote: http://cygwin.com/acronyms/#TOFU > - Original Message - > From: [...] http://cygwin.com/acronyms/#PCYMTNQREAIYR > Could it be that a mount point called /home, or //home (if possible), makes a > difference? Not as far as I can see. Creating a //home mount point (which is not supported anyway) only results in an EACCES error from chdir() rather than ENOENT. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [1.7] bug in chdir
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 7/15/2009 2:46 AM: >> $ cd //home >> $ # huh? no error reported? > > Sorry Eric, but I can't reproduce this. I tried it on XP and 2K8R2 > with identical result. Weird - it's failing for me on my home network as well, and only passing at work (and then, only for certain names). > If you're able to cd to //home, then there must be some crucial > difference in your environment. You should debug this, at least with > strace, so we can find out under what circumstances this occurs. (time passes...) on my home machine: $ uname -a CYGWIN_NT-5.1 LOUNGE 1.7.0(0.212/5/3) 2009-07-13 10:28 i686 Cygwin ... 80 7228161 [main] bash 2228 chdir: dir '//bin' 366 7228527 [main] bash 2228 normalize_posix_path: src //bin 67 7228594 [main] bash 2228 normalize_posix_path: //bin = normalize_posix_path (//bin) 41 7228635 [main] bash 2228 mount_info::conv_to_win32_path: conv_to_win32_path (//bin) 40 7228675 [main] bash 2228 set_flags: flags: binary (0x2) 37 7228712 [main] bash 2228 mount_info::conv_to_win32_path: src_path //bin, dst \\bin, flags 0x2, rc 0 64 7228776 [main] bash 2228 build_fh_pc: fh 0x6123D60C - --- Process 2228, exception 06BA at 7C812AFB 2217 7230993 [main] bash 2228 __set_errno: int chdir(const char*):2569 val 2 73 7231066 [main] bash 2228 chdir: -1 = chdir (//bin) on my work machine: $ uname -a CYGWIN_NT-5.1 EBLAKE 1.7.0(0.212/5/3) 2009-07-13 10:28 i686 Cygwin 56 6950464 [main] bash 25480 chdir: dir '//bin' 28 6950492 [main] bash 25480 normalize_posix_path: src //bin 28 6950520 [main] bash 25480 normalize_posix_path: //bin = normalize_posix_path (//bin) 28 6950548 [main] bash 25480 mount_info::conv_to_win32_path: conv_to_win32_path (//bin) 29 6950577 [main] bash 25480 set_flags: flags: binary (0x2) 27 6950604 [main] bash 25480 mount_info::conv_to_win32_path: src_path //bin, dst \\bin, flags 0x2, rc 0 36 6950640 [main] bash 25480 build_fh_pc: fh 0x6123D6E4 - --- Process 25480, exception 06BA at 7C812AFB 1859 6952499 [main] bash 25480 __set_errno: int chdir(const char*):2569 val 2 39 6952538 [main] bash 25480 chdir: -1 = chdir (//bin) ... 52 796747 [main] bash 12648 chdir: dir '//home' 28 796775 [main] bash 12648 normalize_posix_path: src //home 29 796804 [main] bash 12648 normalize_posix_path: //home = normalize_posix_path (//home) 27 796831 [main] bash 12648 mount_info::conv_to_win32_path: conv_to_win32_path (//home) 29 796860 [main] bash 12648 set_flags: flags: binary (0x2) 28 796888 [main] bash 12648 mount_info::conv_to_win32_path: src_path //home, dst \\home, flags 0x2, rc 0 33 796921 [main] bash 12648 build_fh_pc: fh 0x6123D6E4 69161 866082 [main] bash 12648 mount_info::conv_to_posix_path: conv_to_posix_path (\\home, no-keep-rel, no-add-slash) 45 866127 [main] bash 12648 normalize_win32_path: \\home = normalize_win32_path (\\home) 30 866157 [main] bash 12648 mount_info::conv_to_posix_path: //home = conv_to_posix_path (\\home) 28 866185 [main] bash 12648 chdir: 0 = chdir() cygheap->cwd.posix '//home' native '\??\UN\\home' ... $ ls -dF //eblake //home //bin ls: cannot access //bin: No such file or directory //eblake/ //home/ I guess that means, since //bin failed but //home succeeded, that there is a machine on the domain at my work which is named home but which is offline at the moment? - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpdz6cACgkQ84KuGfSFAYCMpgCfZUkZykAO2SKoOx0diqy8xuWE K+wAoKrIFLnBFjtYsj6N5hHjV0oO6nUP =cHOG -END PGP SIGNATURE- -- 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] bug in chdir
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ashok Vadekar on 7/15/2009 5:23 AM: > Could it be that a mount point called /home, or //home (if possible), makes a > difference? Maybe you're on to something - at work I have: $ mount -m C:/cygwin-2/bin /usr/bin ntfs binary 0 0 C:/cygwin-2/lib /usr/lib ntfs binary 0 0 C:/cygwin/home /home ntfs binary 0 0 none /cygdrive cygdrive binary,posix=0,user 0 0 At home I have: $ mount -m K:/cygwin-2/bin /usr/bin ntfs binary 0 0 K:/cygwin-2/lib /usr/lib ntfs binary 0 0 K:/home /home ntfs binary 0 0 none /cygdrive cygdrive binary,posix=0 0 0 - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpd0FcACgkQ84KuGfSFAYAP9ACgsYZ5JHRZZ+Pl3lp8ilYfKrIO tYwAn0roKzCLzeF/ppR3iIQb7+JeTG9k =JWU2 -END PGP SIGNATURE- -- 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: .#* lock files under X, for files I edit???
Just two fixes for now: Marc Girod wrote: > > This function is intened as a find-file-hook." > ... > (set (make-local-variable 'purify_flag) t > intended purify-flag Marc -- View this message in context: http://www.nabble.com/.-*-lock-files-under-X%2C-for-files-I-edittp23655794p24497846.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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] bug in chdir
On Jul 15 06:46, Eric Blake wrote: > > If you're able to cd to //home, then there must be some crucial > > difference in your environment. You should debug this, at least with > > strace, so we can find out under what circumstances this occurs. > > (time passes...) > [...] >56 6950464 [main] bash 25480 chdir: dir '//bin' >28 6950492 [main] bash 25480 normalize_posix_path: src //bin >28 6950520 [main] bash 25480 normalize_posix_path: //bin = > normalize_posix_path (//bin) >28 6950548 [main] bash 25480 mount_info::conv_to_win32_path: > conv_to_win32_path (//bin) >29 6950577 [main] bash 25480 set_flags: flags: binary (0x2) >27 6950604 [main] bash 25480 mount_info::conv_to_win32_path: src_path > //bin, dst \\bin, flags 0x2, rc 0 >36 6950640 [main] bash 25480 build_fh_pc: fh 0x6123D6E4 > - --- Process 25480, exception 06BA at 7C812AFB > 1859 6952499 [main] bash 25480 __set_errno: int chdir(const char*):2569 val 2 >39 6952538 [main] bash 25480 chdir: -1 = chdir (//bin) > ... >52 796747 [main] bash 12648 chdir: dir '//home' >28 796775 [main] bash 12648 normalize_posix_path: src //home >29 796804 [main] bash 12648 normalize_posix_path: //home = > normalize_posix_path (//home) >27 796831 [main] bash 12648 mount_info::conv_to_win32_path: > conv_to_win32_path (//home) >29 796860 [main] bash 12648 set_flags: flags: binary (0x2) >28 796888 [main] bash 12648 mount_info::conv_to_win32_path: src_path > //home, dst \\home, flags 0x2, rc 0 >33 796921 [main] bash 12648 build_fh_pc: fh 0x6123D6E4 > 69161 866082 [main] bash 12648 mount_info::conv_to_posix_path: > conv_to_posix_path (\\home, no-keep-rel, no-add-slash) >45 866127 [main] bash 12648 normalize_win32_path: \\home = > normalize_win32_path (\\home) >30 866157 [main] bash 12648 mount_info::conv_to_posix_path: //home = > conv_to_posix_path (\\home) >28 866185 [main] bash 12648 chdir: 0 = chdir() cygheap->cwd.posix > '//home' native '\??\UN\\home' Gee! I fixed that in CVS. Fortunately it was only the debug output which was affected by this. > ... > $ ls -dF //eblake //home //bin > ls: cannot access //bin: No such file or directory > //eblake/ //home/ > > > I guess that means, since //bin failed but //home succeeded, that there is > a machine on the domain at my work which is named home but which is > offline at the moment? It seems so. The fact that accessing //home does not create an exception points to a successful SMB name resolution. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [1.7] bug in chdir
Corinna Vinschen cygwin.com> writes: > > $ ls -dF //eblake //home //bin > > ls: cannot access //bin: No such file or directory > > //eblake/ //home/ > > > > > > I guess that means, since //bin failed but //home succeeded, that there is > > a machine on the domain at my work which is named home but which is > > offline at the moment? (confusing enough? who names their work machine 'home'?) > > It seems so. The fact that accessing //home does not create an > exception points to a successful SMB name resolution. Of course, my work domain is so big that 'echo //hom*' takes minutes, due to the large number of known hosts that are not currently accessible, so I can't easily test whether //home is a known host using readdir. But it seems like this problem could be recreated on a much smaller network, by just disconnecting an appropriate machine from the network (although I won't be able to try that until I'm back home). It still seems like chdir() should do some sort of stat() test rather than just a successful SMB name resolution when attempting to change to //name. -- Eric Blake -- 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] bug in chdir
Eric Blake wrote: > Corinna Vinschen cygwin.com> writes: > >>> $ ls -dF //eblake //home //bin >>> ls: cannot access //bin: No such file or directory >>> //eblake/ //home/ >>> >>> >>> I guess that means, since //bin failed but //home succeeded, that there is >>> a machine on the domain at my work which is named home but which is >>> offline at the moment? > > (confusing enough? who names their work machine 'home'?) WAG: somebody's brought in their laptop from home, and plugged it into the corporate LAN, and it's not even joined to the domain, but it has "simple file sharing" enabled and it's created a workgroup for itself; "home" is the workgroup name. nbtstat may be your friend here if you want to take a look around for it. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [1.7] bug in chdir
On Jul 15 13:58, Eric Blake wrote:
> Corinna Vinschen cygwin.com> writes:
> > The fact that accessing //home does not create an
> > exception points to a successful SMB name resolution.
> [...]
> It still seems like chdir() should do some
> sort of stat() test rather than just a successful SMB name resolution when
> attempting to change to //name.
That's not that easy. Since there's no real path //server supported in
Windows Cygwin has to rely on WNetGetResourceInformation for the
existence check and if the existence is confirmed, it allows to open a
file descriptor to this virtual path.
I created a patch which uses WNetOpenEnum for the existence check, but
it needs extremly long to timeout the existence check in such a case.
I assume you're set up to build your own Cygwin DLL, so you may try the
below patch. I'm not yet convinced it's a good thing to apply it,
though. It potentially slows down net operation a lot for the sake of a
rare border case. Frying pan, Fire. Anyway, please give it a try.
Index: fhandler_netdrive.cc
===
RCS file: /cvs/src/src/winsup/cygwin/fhandler_netdrive.cc,v
retrieving revision 1.24
diff -u -p -r1.24 fhandler_netdrive.cc
--- fhandler_netdrive.cc15 Jul 2009 14:31:51 - 1.24
+++ fhandler_netdrive.cc15 Jul 2009 14:40:58 -
@@ -164,15 +164,20 @@ fhandler_netdrive::exists ()
*to = (*from == '/') ? '\\' : *from;
*to = '\0';
+ struct net_hdls nh = { NULL, NULL };
NETRESOURCE nr = {0};
- nr.dwScope = RESOURCE_GLOBALNET;
nr.dwType = RESOURCETYPE_DISK;
- nr.lpLocalName = NULL;
nr.lpRemoteName = namebuf;
- DWORD ret = create_thread_and_wait (GET_RESOURCE_INFO, &nr, NULL, 0,
- "WNetGetResourceInformation");
- if (ret != ERROR_MORE_DATA && ret != NO_ERROR)
-return 0;
+ DWORD ret = create_thread_and_wait (GET_RESOURCE_OPENENUM,
+ &nr, &nh, 0, "WNetOpenEnum");
+ if (ret != NO_ERROR)
+{
+ if (nh.dom)
+ WNetCloseEnum (nh.dom);
+ if (nh.net)
+ WNetCloseEnum (nh.net);
+ return 0;
+}
return 1;
}
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
OpenSSH login failing thru PuTTY/plink
Hi,
I've installed and configured OpenSSH on two Windows 2003 Server / Cygwin
machines ("chaplab1" and "chaplab2"). I've tried, with PuTTY and plink.exe
on a Windows 2003 machine on the same LAN, to connect chaplab2, and get
"failed to authenticate". But I *can* PuTTY to chaplab1/Cygwin, and from
its command line I can ssh into chaplab2.
All three nodes are on 192.168.*
Both chaplab1 and chaplab2's host.allow & host.deny files are identical:
host.allow:
sshd: ALL
host.deny:
ALL:ALL EXCEPT localhost AND '192.168.':DENY
In fact, chaplab 1&2 should be identical in as many ways as possible.
Can anyone suggest a next step to try?
Thanks
Chap
--
View this message in context:
http://www.nabble.com/OpenSSH-login-failing-thru-PuTTY-plink-tp24500041p24500041.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
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: perl threads on 2008 R2 64bit = crash ( was: perl 5.10 threads on 1.5.25 = instant crash )
On Jul 15 01:41, Steven Hartland wrote:
>
> - Original Message - From: "Christopher Faylor"
>
http://cygwin.com/acronyms/#PCYMTNQREAIYR
>> On Wed, Jul 15, 2009 at 12:36:56AM +0100, Steven Hartland wrote:
>>> This may or may not help:
>>>
>>> According to VC++ debugger it always dies with:
>>> Unhandled exception at 0x610d089d in perl.exe: 0xC005: Access violation
>>> reading location 0x0004.
>>
>> No, sorry, it really doesn't help. The VC++ debugger doesn't know how
>> to handle cygwin exceptions.
>
> Was just trying to get a hint of the area of the problem since gdb doesn't
> actually break when it happens this seemed to be the only way to get that
> info.
>
> Any pointers on how I can help narrow down the issue?
I can reproduce the problem on my 2008 R2 box. It works fine on Windows
7 x64, though, so it's a Server thingy.
What happens is that this statement
if ((*object)->magic != magic)
in the function thread.cc:verifyable_object_isvalid throws an exception
because *object is NULL. This should be covered by the myfault handler
in this function but for some reason it isn't.
To debug this further I created a STC(TM)(*) which does the same as the
Perl testcase, just in pure C:
SNIP
#include
#include
#include
pthread_attr_t attr;
void *thr (void *arg)
{
printf ("I'm a thread\n");
return NULL;
}
int main()
{
pthread_t t;
int i, r;
void *ret;
fprintf (stderr, "Testing threads...\n");
i = pthread_attr_init (&attr);
printf ("i = %d\n", i);
r = pthread_create (&t, &attr, thr, NULL);
if (r)
fprintf (stderr, "pthread_create: %d %s\n", errno, strerror (errno));
else
pthread_join (t, &ret);
fprintf (stderr, "Testing done\n");
return 0;
}
SNAP
The problem is, this testcase works fine, even on 2008 R2. It must
have something to do with the way Perl creates thread or does its
own exception handling. I just don't know what to look for.
Corinna
(*) http://cygwin.com/acronyms/#STC
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Sending data to a script over SSH
defaria wrote: > > Why are you trying to deal with a very manual, step by step, point and > click method of thinking and doing? The basic task here is to get data > from an Excel worksheet (which is not a good input method to start with) > to a text file. There are programmatic ways to do this. You can, for > example, extract data from an Excel spreadsheet using Perl. > This is not *my* preferred way of doing things; it's the way my colleagues are used to doing things. To put it mildly, they don't work smart. I'm trying to gently introduce them to the amazing world of automation while not upsetting them completely :-D . Eventually, when they realize that Mr. Computer can save them hours and days of mind-numbing drudgery and carpal tunnel syndrome, the scales may fall from Mr. Boss-man's eyes and he'll ask me to build something that'll be *really* easy to use. defaria wrote: > >> From Cygwin, I can get at the clipboard through /dev/clipboard - very >> handy indeed! Only problem is that this requires that Cygwin be >> running in the same copy of Windows from which I'm doing the cutting >> and pasting. This turns out to be a hard sell to management, who'd >> prefer that I keep Cygwin running in its own Windows environment. > This part didn't parse for me. Wouldn't running Cygwin on the machine > you are doing the cutting and pasting be it's own Windows environment?!? > Well, not nearly so much as having it run in a separate machine. I don't know exactly how deeply it ties itself into the Windows OS (I know virtually nothing about Windows), but I *do* know that if anything happened on the Windows machine (that's shared by several users), suspicion would immediately fall on Cygwin. My boss worked for IBM for ten years, in Marketing. Fear, uncertainty, and doubt run deep for him. I'd like to run Cygwin directly on the "production" machine (it has been superbly reliable for me) but superstition is tough to battle directly. -- View this message in context: http://www.nabble.com/Sending-data-to-a-script-over-SSH-tp24284928p24500709.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: perl threads on 2008 R2 64bit = crash ( was: perl 5.10 threads on 1.5.25 = instant crash )
Corinna Vinschen wrote: > What happens is that this statement > > if ((*object)->magic != magic) > > in the function thread.cc:verifyable_object_isvalid throws an exception > because *object is NULL. This should be covered by the myfault handler > in this function but for some reason it isn't. So, set a "*object == 0" conditional breakpoint on that line and see what the SEH chain looks like? cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Sending data to a script over SSH
Chap Harrison wrote: > > defaria wrote: >> Why are you trying to deal with a very manual, step by step, point and >> click method of thinking and doing? The basic task here is to get data >> from an Excel worksheet (which is not a good input method to start with) >> to a text file. There are programmatic ways to do this. You can, for >> example, extract data from an Excel spreadsheet using Perl. >> > > This is not *my* preferred way of doing things; it's the way my colleagues > are used to doing things. To put it mildly, they don't work smart. I'm > trying to gently introduce them to the amazing world of automation while not > upsetting them completely :-D . Eventually, when they realize that Mr. > Computer can save them hours and days of mind-numbing drudgery and carpal > tunnel syndrome, the scales may fall from Mr. Boss-man's eyes and he'll ask > me to build something that'll be *really* easy to use. Failing that, you at least have a rich seam of material to mine for stories to submit to http://thedailywtf.com/ :-/ > defaria wrote: >> This part didn't parse for me. Wouldn't running Cygwin on the machine >> you are doing the cutting and pasting be it's own Windows environment?!? > > Well, not nearly so much as having it run in a separate machine. I don't > know exactly how deeply it ties itself into the Windows OS (I know virtually > nothing about Windows), but I *do* know that if anything happened on the > Windows machine (that's shared by several users), suspicion would > immediately fall on Cygwin. For the record, Cygwin does not "tie itself into the OS" deeply or even at all, not in the slightest. It is an entirely ordinary windows program running in user mode. It has the ability to install services (which are also just ordinary user-mode executables), and there is in one case - libusb - a kernel-mode device driver; you'd want to not install that. But that one exception aside, everything cygwin is and does is just a win32 program and a bunch of win32 DLLs. It cannot BSoD the machine, crash non-cygwin processes, or corrupt the kernel, it does not do low-level disk i/o, it no more hooks itself into the OS than notepad or solitaire. > My boss worked for IBM for ten years, in Marketing. Fear, uncertainty, and > doubt run deep for him. I'd like to run Cygwin directly on the "production" > machine (it has been superbly reliable for me) but superstition is tough to > battle directly. Oh dear, doesn't sound like mere facts alone will be much use to you! cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl threads on 2008 R2 64bit = crash ( was: perl 5.10 threads on 1.5.25 = instant crash )
On Wed, Jul 15, 2009 at 05:03:43PM +0100, Dave Korn wrote: >Corinna Vinschen wrote: > >> What happens is that this statement >> >> if ((*object)->magic != magic) >> >> in the function thread.cc:verifyable_object_isvalid throws an exception >> because *object is NULL. This should be covered by the myfault handler >> in this function but for some reason it isn't. > > So, set a "*object == 0" conditional breakpoint on that line and see what >the SEH chain looks like? But the point is that this shouldn't have caused a SEGV. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl threads on 2008 R2 64bit = crash ( was: perl 5.10 threads on 1.5.25 = instant crash )
On Wed, Jul 15, 2009 at 05:21:39PM +0200, Corinna Vinschen wrote:
>On Jul 15 01:41, Steven Hartland wrote:
>>
>> - Original Message - From: "Christopher Faylor"
>>
>
>http://cygwin.com/acronyms/#PCYMTNQREAIYR
>
>>> On Wed, Jul 15, 2009 at 12:36:56AM +0100, Steven Hartland wrote:
This may or may not help:
According to VC++ debugger it always dies with:
Unhandled exception at 0x610d089d in perl.exe: 0xC005: Access
violation reading location 0x0004.
>>>
>>> No, sorry, it really doesn't help. The VC++ debugger doesn't know how
>>> to handle cygwin exceptions.
>>
>> Was just trying to get a hint of the area of the problem since gdb doesn't
>> actually break when it happens this seemed to be the only way to get that
>> info.
>>
>> Any pointers on how I can help narrow down the issue?
>
>I can reproduce the problem on my 2008 R2 box. It works fine on Windows
>7 x64, though, so it's a Server thingy.
>
>What happens is that this statement
>
> if ((*object)->magic != magic)
>
>in the function thread.cc:verifyable_object_isvalid throws an exception
>because *object is NULL. This should be covered by the myfault handler
>in this function but for some reason it isn't.
>
>To debug this further I created a STC(TM)(*) which does the same as the
>Perl testcase, just in pure C:
>
> SNIP
>#include
>#include
>#include
>
>pthread_attr_t attr;
>
>void *thr (void *arg)
>{
> printf ("I'm a thread\n");
> return NULL;
>}
>
>int main()
>{
> pthread_t t;
> int i, r;
> void *ret;
>
> fprintf (stderr, "Testing threads...\n");
> i = pthread_attr_init (&attr);
> printf ("i = %d\n", i);
> r = pthread_create (&t, &attr, thr, NULL);
> if (r)
>fprintf (stderr, "pthread_create: %d %s\n", errno, strerror (errno));
> else
>pthread_join (t, &ret);
> fprintf (stderr, "Testing done\n");
> return 0;
>}
> SNAP
I can't try this right now myself but what about trying various settings
for a SIGSEGV signal handler?
cgf
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl threads on 2008 R2 64bit = crash ( was: perl 5.10 threads on 1.5.25 = instant crash )
Christopher Faylor wrote: > On Wed, Jul 15, 2009 at 05:03:43PM +0100, Dave Korn wrote: >> Corinna Vinschen wrote: >> >>> What happens is that this statement >>> >>> if ((*object)->magic != magic) >>> >>> in the function thread.cc:verifyable_object_isvalid throws an exception >>> because *object is NULL. This should be covered by the myfault handler >>> in this function but for some reason it isn't. >> So, set a "*object == 0" conditional breakpoint on that line and see what >> the SEH chain looks like? > > But the point is that this shouldn't have caused a SEGV. Don't understand quite what you're alluding to. Where did Corinna refer to a SEGV? Unless we're using the words differently, a SEGV is a signal, which is a cygwin posix construct generated in response to an unhandled x86 access violation exception. Corinna said that the call to v_o_i caused an *exception*, as dereferencing a NULL pointer always does, and that it should have been covered by the myfault handler (which as far as I know works by wrapping an SEH handler around the block of protected code, and using it to catch exceptions and longjmp back to the receiver) and which might lead to a SEGV signal being generated somewhere a long way down the road if it failed to catch the exception, but I'm just concentrating on the point of failure. Hence my suggestion to breakpoint it just before the exception happens and see what the state of the SEH chain looks like. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: .#* lock files under X, for files I edit???
> (set (make-local-variable 'purify_flag) t Setting purify-flag wasn't working for me (emacs gave a message about an assertion failure). And my attempt to write an advice didn't seem to work any better (unless I didn't do it correctly): (defadvice lock-buffer (around clearcase-no-lock activate) "Under ClearCase, in Cygwin, do not create lock symlinks. Either format (old: Windows shortcuts; new: real symlinks with utf name) are bad for different reasons." (unless (file-accessible-directory-p (concat (buffer-file-name) "@@")) ad-do-it)) Rather, it seems that the REAL problem is that cygwin1.dll cannot recognize attempts to create symlinks on the clearcase MVFS file system. $ df -T . FilesystemType 1K-blocks Used Available Use% Mounted on M:/u_fabt_eblake unknown 1024000512000512000 50% /project/fabt $ volinfo . Device Type: 7 Characteristics: 10 Volume Name: Serial Number : 36984713 Max Filenamelength : 255 Filesystemname : Flags : 3 FILE_CASE_SENSITIVE_SEARCH : TRUE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: FALSE FILE_PERSISTENT_ACLS: FALSE FILE_FILE_COMPRESSION : FALSE FILE_VOLUME_QUOTAS : FALSE FILE_SUPPORTS_SPARSE_FILES : FALSE FILE_SUPPORTS_REPARSE_POINTS: FALSE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: FALSE FILE_SUPPORTS_ENCRYPTION: FALSE FILE_NAMED_STREAMS : FALSE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE $ touch foo $ ln -s foo bar $ readlink bar || echo $? 1 $ cat bar !~foo $ file bar bar: data Maybe we should be trying to change cygwin to cause symlink() to fail with a proper errno on MVFS, and then revisit the emacs side of the equation to see how emacs handles failure to create a symlink when errno is ENOSYS (or whatever errno cygwin uses). Or maybe it is just a matter of detecting that if the file system does not support DOS attributes (which are essential in creating new-style symlinks), that an old-style symlink must be created on that filesystem. -- Eric Blake -- View this message in context: http://www.nabble.com/.-*-lock-files-under-X%2C-for-files-I-edittp23655794p24501895.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: perl threads on 2008 R2 64bit = crash ( was: perl 5.10 threads on 1.5.25 = instant crash )
On Jul 15 12:23, Christopher Faylor wrote:
> On Wed, Jul 15, 2009 at 05:21:39PM +0200, Corinna Vinschen wrote:
> > SNIP
> >#include
> >#include
> >#include
> >
> >pthread_attr_t attr;
> >
> >void *thr (void *arg)
> >{
> > printf ("I'm a thread\n");
> > return NULL;
> >}
> >
> >int main()
> >{
> > pthread_t t;
> > int i, r;
> > void *ret;
> >
> > fprintf (stderr, "Testing threads...\n");
> > i = pthread_attr_init (&attr);
> > printf ("i = %d\n", i);
> > r = pthread_create (&t, &attr, thr, NULL);
> > if (r)
> >fprintf (stderr, "pthread_create: %d %s\n", errno, strerror (errno));
> > else
> >pthread_join (t, &ret);
> > fprintf (stderr, "Testing done\n");
> > return 0;
> >}
> > SNAP
>
> I can't try this right now myself but what about trying various settings
> for a SIGSEGV signal handler?
No SIGSEGV setting has any visible effect. In the Perl testcase
_cygtls::handle_exceptions is just not called, in the C testcase
it's always called.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [1.7] bug in chdir
Corinna Vinschen cygwin.com> writes: > I created a patch which uses WNetOpenEnum for the existence check, but > it needs extremly long to timeout the existence check in such a case. There's already a long timeout on unknown names; that's inescapable when dealing with // issues. Without the patch: $ time dash -c 'cd //bin' cd: 1: can't cd to //bin real0m6.921s user0m0.046s sys 0m0.015s $ time dash -c 'cd //home' # wrong result real0m0.187s user0m0.030s sys 0m0.030s $ time dash -c 'cd //eblake' real0m0.031s user0m0.030s sys 0m0.015s With the patch, I see: $ time dash -c 'cd //bin' cd: 1: can't cd to //bin real0m4.796s user0m0.030s sys 0m0.030s $ time dash -c 'cd //home' # right result cd: 1: can't cd to //home real0m0.031s user0m0.030s sys 0m0.015s $ time dash -c 'cd //eblake' real0m0.031s user0m0.030s sys 0m0.015s So, no obvious speed regression on good paths, a whopping 25% performance improvement on paths that previously failed, and the desired failure on the questionable path is now achieved with speed comparable to the success path! I'd say go ahead and apply the patch - the numbers speak for themselves. -- Eric Blake -- 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: .#* lock files under X, for files I edit???
On Jul 15 09:49, Eric Blake wrote: > Rather, it seems that the REAL problem is that cygwin1.dll cannot > recognize attempts to create symlinks on the clearcase MVFS file system. > > $ df -T . > FilesystemType 1K-blocks Used Available Use% Mounted on > M:/u_fabt_eblake >unknown 1024000512000512000 50% /project/fabt > $ volinfo . > Device Type: 7 > Characteristics: 10 > Volume Name: > Serial Number : 36984713 > Max Filenamelength : 255 > Filesystemname : > Flags : 3 > FILE_CASE_SENSITIVE_SEARCH : TRUE > FILE_CASE_PRESERVED_NAMES : TRUE > FILE_UNICODE_ON_DISK: FALSE > FILE_PERSISTENT_ACLS: FALSE > FILE_FILE_COMPRESSION : FALSE > FILE_VOLUME_QUOTAS : FALSE > FILE_SUPPORTS_SPARSE_FILES : FALSE > FILE_SUPPORTS_REPARSE_POINTS: FALSE > FILE_SUPPORTS_REMOTE_STORAGE: FALSE > FILE_VOLUME_IS_COMPRESSED : FALSE > FILE_SUPPORTS_OBJECT_IDS: FALSE > FILE_SUPPORTS_ENCRYPTION: FALSE > FILE_NAMED_STREAMS : FALSE > FILE_READ_ONLY_VOLUME : FALSE > FILE_SEQUENTIAL_WRITE_ONCE : FALSE > FILE_SUPPORTS_TRANSACTIONS : FALSE > $ touch foo > $ ln -s foo bar > $ readlink bar || echo $? > 1 > $ cat bar > !~foo > $ file bar > bar: data > > Maybe we should be trying to change cygwin to cause > symlink() to fail with a proper errno on MVFS, and then > revisit the emacs side of the equation to see how emacs > handles failure to create a symlink when errno is ENOSYS > (or whatever errno cygwin uses). Or maybe it is just > a matter of detecting that if the file system does not > support DOS attributes (which are essential in creating > new-style symlinks), that an old-style symlink must be > created on that filesystem. That's something we can do. I'll look into it. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: .#* lock files under X, for files I edit???
Eric Blake wrote: > >> (set (make-local-variable 'purify_flag) t > > Setting purify-flag wasn't working for me (emacs gave a message > about an assertion failure). > Huh? Nothing like that here. In fact, it works... Wait: - I still have the 'CYGWIN=winsymlinks' setting --although unsetting it doesn't affect - there was this typo on purify_flag --but I assume you saw it: dash, not underscore Eric Blake wrote: > > Rather, it seems that the REAL problem is that cygwin1.dll cannot > recognize attempts to create symlinks on the clearcase MVFS file system. > OK. However, it is and was able to create something. My problem has been that it wasn't able to remove them. Eric Blake wrote: > > Maybe we should be trying to change cygwin to cause > symlink() to fail with a proper errno on MVFS, and then > revisit the emacs side of the equation to see how emacs > handles failure to create a symlink when errno is ENOSYS > (or whatever errno cygwin uses). Or maybe it is just > a matter of detecting that if the file system does not > support DOS attributes (which are essential in creating > new-style symlinks), that an old-style symlink must be > created on that filesystem. > OK again. Now you are already much deeper than I ever was in the causes. The MVFS doesn't support DOS attributes? I have no clue about that. How may I check this? Interesting... makesystem> type volinfo bash: type: volinfo: not found makesystem> cygcheck -p volinfo Found 0 matches for volinfo. makesystem> df -T . FilesystemType 1K-blocks Used Available Use% Mounted on X: unknown8192 3072 5120 38% /cygdrive/x Note: I am one version behind with cygwin: 1.7.0-50 makesystem> touch foo makesystem> ln -s foo bar makesystem> readlink bar || echo $? foo makesystem> file bar bar: symbolic link to `foo' makesystem> ll bar lrwxrwxrwx 1 emagiro EEI-ATusers 3 Jul 15 18:56 bar -> foo makesystem> rm bar rm: cannot remove `bar': Permission denied makesystem> ct pwv Working directory view: emagiro_86 Set view: emagiro_86 makesystem> export CYGWIN=tty makesystem> ln -s foo zoo makesystem> readlink zoo || echo $? 1 makesystem> ll zoo -rw-r--r-- 1 emagiro EEI-ATusers 20 Jul 15 18:58 zoo makesystem> file zoo zoo: data makesystem> od -c zoo 000 ! < s y m l i n k > 377 376 f \0 o \0 020 o \0 \0 \0 024 makesystem> rm zoo makesystem> I confirm that my find-file-hook works. I didn't want to restart my emacs, but I tried with: (setenv "CYGWIN" "tty") "tty" in the *scratch* buffer, and opening an existing checked-out file. No lock created. Marc -- View this message in context: http://www.nabble.com/.-*-lock-files-under-X%2C-for-files-I-edittp23655794p24503085.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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] bug in chdir
On Jul 15 17:38, Eric Blake wrote: > Corinna Vinschen cygwin.com> writes: > > > I created a patch which uses WNetOpenEnum for the existence check, but > > it needs extremly long to timeout the existence check in such a case. > [...] > So, no obvious speed regression on good paths, a whopping 25% performance > improvement on paths that previously failed, and the desired failure on the > questionable path is now achieved with speed comparable to the success path! > I'd say go ahead and apply the patch - the numbers speak for themselves. Thanks for testing. Checked in. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: .#* lock files under X, for files I edit???
On Jul 15 11:08, Marc Girod wrote: > OK again. Now you are already much deeper than I ever > was in the causes. > The MVFS doesn't support DOS attributes? > I have no clue about that. > How may I check this? Interesting... Try this on the MVFS FS: $ touch foo $ attrib foo AX:\foo $ attrib +r +s foo $ attrib foo A S R X:\foo If you don't get the above result, MVFS doesn't support DOS attributes, or it only supports them partially. It would be helpful to get this information exactly from somebody using MVFS. 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
[1.7] unzip is OK, zip is not
I have been running Cygwin 1.7 for a while. There is one annoying problem, when ZIP/UNZIP were installed, I have an unzip.exe executable, but no zip.exe executable. This doesn't matter in *sh shells, but does matter when I'm using Cygwin in a "DOS" window: c:\>which unzip unzip is an external : C:\Cygwin\bin\unzip.exe c:\>which zip zip is an unknown command Is there a way to fix this (other than by making another copy of the file)? 3/01/2009 21:11 81,408 bunzip2.exe 3/01/2009 21:11 81,408 bzip2.exe 3/01/2009 21:11 7,680 bzip2recover.exe 3/05/2009 23:51 17,920 funzip.exe 7/23/2007 15:14 65 gunzip 7/23/2007 15:14 56,832 gzip.exe 12/18/2007 5:45 5,656 preunzip 12/18/2007 5:45 5,656 prezip 12/18/2007 5:45 5,632 prezip-bin.exe 3/05/2009 23:51 115,200 unzip.exe 3/05/2009 23:51 55,296 unzipsfx.exe 3/05/2009 23:43 197,839 zip 3/05/2009 23:43 89,309 zipcloak 3/05/2009 23:50 1,188 zipgrep 3/05/2009 23:51 115,200 zipinfo.exe 3/05/2009 23:43 84,001 zipnote 3/05/2009 23:43 87,384 zipsplit Thanks - Jim -- Jim Reisert AD1C, , http://www.ad1c.us -- 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: Possible Bug or limitation in Cygwin 1.7 and Rsync and file number limit
snip< I just discovered some additional information that may help get to the bottom of this. Not sure what made me think of this, but I decided to try an older version of rsync. If I run rsync 3.0.4-1 or 3.0.5-1, I experience the problem. However, when I run 2.6.9-2, the only other version of rsync I can find built specifically for cygwin 1.7, the problem goes away and all works fine? By the way Corinna, in case I didn't say it before, thank you very much for trying to help out and for the time you spend on this project! - Kyle I realize this problem wasn't being worked on as the developers could not reproduce it however I thought I would give an update just the same. I downloaded the latest version of the 1.7 cygwin1.dll this morning dated 7-13-2009 and this problem is now fixed. If I put the old 1.7 dll in place (dated 6-18-2009), the problem immediately returns. So whatever the problem was, this latest build seems to have corrected it. Thanks to all for the hard work in maintaining cygwin! - Kyle -- 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] unzip is OK, zip is not
Jim Reisert AD1C wrote: > I have been running Cygwin 1.7 for a while. > > There is one annoying problem, when ZIP/UNZIP were installed, I have > an unzip.exe executable, but no zip.exe executable. This doesn't > matter in *sh shells, but does matter when I'm using Cygwin in a "DOS" > window: > >c:\>which unzip >unzip is an external : C:\Cygwin\bin\unzip.exe > >c:\>which zip >zip is an unknown command > > Is there a way to fix this (other than by making another copy of the file)? Known packaging error in zip-3.0-10. I haven't had a chance to respin and push zip-3.0-11 yet. Just 'mv zip zip.exe' for now. -- Chuck -- 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: perl threads on 2008 R2 64bit = crash ( was: perl 5.10 threads on 1.5.25 = instant crash )
On Wed, Jul 15, 2009 at 05:58:25PM +0100, Dave Korn wrote: >Christopher Faylor wrote: >> On Wed, Jul 15, 2009 at 05:03:43PM +0100, Dave Korn wrote: >>> Corinna Vinschen wrote: >>> What happens is that this statement if ((*object)->magic != magic) in the function thread.cc:verifyable_object_isvalid throws an exception because *object is NULL. This should be covered by the myfault handler in this function but for some reason it isn't. >>> So, set a "*object == 0" conditional breakpoint on that line and see what >>> the SEH chain looks like? >> >> But the point is that this shouldn't have caused a SEGV. > > Don't understand quite what you're alluding to. Where did Corinna refer to >a SEGV? Unless we're using the words differently, a SEGV is a signal, which >is a cygwin posix construct generated in response to an unhandled x86 access >violation exception. Corinna said that the call to v_o_i caused an >*exception*, as dereferencing a NULL pointer always does, and that it should >have been covered by the myfault handler (which as far as I know works by >wrapping an SEH handler around the block of protected code, and using it to >catch exceptions and longjmp back to the receiver) and which might lead to a >SEGV signal being generated somewhere a long way down the road if it failed to >catch the exception, but I'm just concentrating on the point of failure. >Hence my suggestion to breakpoint it just before the exception happens and see >what the state of the SEH chain looks like. The point is that this is generating the equivalent of a SEGV without ever hitting Cygwin's "SEH" code. Setting a breakpoint on the line would likely just show you the call stack but would not provide any insight into why the myfault was not invoked. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl threads on 2008 R2 64bit = crash ( was: perl 5.10 threads on 1.5.25 = instant crash )
- Original Message - From: "Christopher Faylor" The point is that this is generating the equivalent of a SEGV without ever hitting Cygwin's "SEH" code. Setting a breakpoint on the line would likely just show you the call stack but would not provide any insight into why the myfault was not invoked. Of note when running 1.5.25 I did get the windows application error dialog, but with 1.7 and the latest snapshot it doesn't, so maybe using 1.5.25 might help? Regards Steve -- 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: perl threads on 2008 R2 64bit = crash ( was: perl 5.10 threads on 1.5.25 = instant crash )
Christopher Faylor wrote: > On Wed, Jul 15, 2009 at 05:58:25PM +0100, Dave Korn wrote: >> Christopher Faylor wrote: >>> On Wed, Jul 15, 2009 at 05:03:43PM +0100, Dave Korn wrote: Corinna Vinschen wrote: > What happens is that this statement > > if ((*object)->magic != magic) > > in the function thread.cc:verifyable_object_isvalid throws an exception > because *object is NULL. This should be covered by the myfault handler > in this function but for some reason it isn't. So, set a "*object == 0" conditional breakpoint on that line and see what the SEH chain looks like? >>> But the point is that this shouldn't have caused a SEGV. >> Don't understand quite what you're alluding to. Where did Corinna refer to >> a SEGV? Unless we're using the words differently, a SEGV is a signal, which >> is a cygwin posix construct generated in response to an unhandled x86 access >> violation exception. Corinna said that the call to v_o_i caused an >> *exception*, as dereferencing a NULL pointer always does, and that it should >> have been covered by the myfault handler (which as far as I know works by >> wrapping an SEH handler around the block of protected code, and using it to >> catch exceptions and longjmp back to the receiver) and which might lead to a >> SEGV signal being generated somewhere a long way down the road if it failed >> to >> catch the exception, but I'm just concentrating on the point of failure. >> Hence my suggestion to breakpoint it just before the exception happens and >> see >> what the state of the SEH chain looks like. > > The point is that this is generating the equivalent of a SEGV without > ever hitting Cygwin's "SEH" code. Setting a breakpoint on the line > would likely just show you the call stack but would not provide any > insight into why the myfault was not invoked. Yes. That's why I said "examine the SEH chain", not "look at the call stack". I reckoned that doing so might provide any insight into why the myfault was not invoked. For instance, you might see something hooked into the SEH chain ahead of Cygwin's handler and start to look at what it was and where it came from; and if not, you would be able to infer that the SEH chain was not being invoked and start looking at the various SEH security enhancements in recent windows versions and wondering which one might make it think it shouldn't call handlers from a non-registered stack-based SEH registration record. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
MVFS results
New thread (gmane gave me grief at finding the old one, and anyways, I'm adding a couple new topics to the mix). $ attrib foo M:\foo $ attrib +r +s foo $ attrib foo R M:\foo $ rm foo rm: remove write-protected regular empty file `foo'? y rm: cannot remove `foo': Permission denied $ attrib -r foo $ rm foo Just as we suspected, MVFS doesn't support DOS attributes, which also interferes with deletion abilities (I can also use 'chmod a+w' instead of 'attrib -r' to get deletion to work). Another one that's been bothering me: cp -p can't preserve times when copying from a remote drive (I'm not sure if it is samba, NFS, or something else) over to MVFS, but touch can; also, copying from local to MVFS has no problems preserving times: $ echo > /tmp/bar $ cp -p /cygdrive/f/foo . # remote to MVFS $ ls -l /cygdrive/f/foo foo --+ 1 eblake Domain Users 925184 Nov 4 2004 cygdrive/f/foo -r--r--r-- 1 eblake Domain Users 925184 Jul 15 13:33 foo $ touch --ref cygdrive/f/foo foo $ ls -l /cygdrive/f/foo foo --+ 1 eblake Domain Users 925184 Nov 4 2004 /cygdrive/f/foo -r--r--r-- 1 eblake Domain Users 925184 Nov 4 2004 foo $ cp -p /tmp/bar bar# local to MVFS $ ll /tmp/bar bar -rw-r- 1 eblake Domain Users 1 Jul 15 13:26 /tmp/bar -rw-r--r-- 1 eblake Domain Users 1 Jul 15 13:26 bar $ touch bar $ ll /tmp/bar bar -rw-r- 1 eblake Domain Users 1 Jul 15 13:26 /tmp/bar -rw-r--r-- 1 eblake Domain Users 1 Jul 15 13:37 bar Do you need any straces for any of these actions? Also, volinfo is such a helpful debug utility; should we go ahead and add it to the utils directory, and compile it alongside other tools like cygcheck as part of the base package? $ volinfo /cygdrive/f/ Device Type: 7 Characteristics: 10 Volume Name: Serial Number : 1414974143 Max Filenamelength : 255 Filesystemname : Flags : 700ff FILE_CASE_SENSITIVE_SEARCH : TRUE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: TRUE FILE_PERSISTENT_ACLS: TRUE FILE_FILE_COMPRESSION : TRUE FILE_VOLUME_QUOTAS : TRUE FILE_SUPPORTS_SPARSE_FILES : TRUE FILE_SUPPORTS_REPARSE_POINTS: TRUE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: TRUE FILE_SUPPORTS_ENCRYPTION: TRUE FILE_NAMED_STREAMS : TRUE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE $ volinfo /tmp Device Type: 7 Characteristics: 20 Volume Name: <> Serial Number : 1277927559 Max Filenamelength : 255 Filesystemname : Flags : 700ff FILE_CASE_SENSITIVE_SEARCH : TRUE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: TRUE FILE_PERSISTENT_ACLS: TRUE FILE_FILE_COMPRESSION : TRUE FILE_VOLUME_QUOTAS : TRUE FILE_SUPPORTS_SPARSE_FILES : TRUE FILE_SUPPORTS_REPARSE_POINTS: TRUE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: TRUE FILE_SUPPORTS_ENCRYPTION: TRUE FILE_NAMED_STREAMS : TRUE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE [For the record, I hate clearcase - I'd much rather use git. Whoever thought turning a version control system into a file system made sense must have been on something at the time.] -- Eric Blake -- 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: perl threads on 2008 R2 64bit = crash ( was: perl 5.10 threads on 1.5.25 = instant crash )
On Jul 15 20:32, Dave Korn wrote: > Yes. That's why I said "examine the SEH chain", not "look at the call > stack". I reckoned that doing so might provide any insight into why the > myfault was not invoked. For instance, you might see something hooked into > the SEH chain ahead of Cygwin's handler and start to look at what it was and > where it came from; and if not, you would be able to infer that the SEH chain > was not being invoked and start looking at the various SEH security > enhancements in recent windows versions and wondering which one might make it > think it shouldn't call handlers from a non-registered stack-based SEH > registration record. I'm not opposed to get some help with this stuff... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: OpenSSH login failing thru PuTTY/plink
From: Chap Harrison
Date: Wed, Jul 15, 2009 at 08:16:05AM -0700
>
> Hi,
>
> I've installed and configured OpenSSH on two Windows 2003 Server / Cygwin
> machines ("chaplab1" and "chaplab2"). I've tried, with PuTTY and plink.exe
> on a Windows 2003 machine on the same LAN, to connect chaplab2, and get
> "failed to authenticate". But I *can* PuTTY to chaplab1/Cygwin, and from
> its command line I can ssh into chaplab2.
>
> All three nodes are on 192.168.*
>
> Both chaplab1 and chaplab2's host.allow & host.deny files are identical:
>
> host.allow:
> sshd: ALL
>
> host.deny:
> ALL:ALL EXCEPT localhost AND '192.168.':DENY
>
> In fact, chaplab 1&2 should be identical in as many ways as possible.
>
> Can anyone suggest a next step to try?
>
any messages in the ssh logs on the servers? Any difference if you run
sshd with debug on on the servers?
Kind regards,
Jurriaan
--
"A moment," said Reith. "At a conscious level I am convinced of your
integrity, but I can't control my instinctive suspicions. Let us make
the arrangements together."
Jack Vance - Servants of the Wankh
--
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: MVFS results
Eric Blake wrote: > Also, volinfo is such a helpful debug utility; should we go ahead and add it > to > the utils directory, and compile it alongside other tools like cygcheck as > part > of the base package? It's already in the csih package, under /usr/lib/csih/ but if you want to "promote" it to src/winsup/ that's fine. When/if that happens, we'll need to coordinate the release of cygwin-1.7.x-y and the new csih. -- Chuck -- 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
volinfo (was: MVFS results)
Charles Wilson cwilson.fastmail.fm> writes: > > Eric Blake wrote: > > Also, volinfo is such a helpful debug utility; should we go ahead and add it to > > the utils directory, and compile it alongside other tools like cygcheck as part > > of the base package? > > It's already in the csih package, under /usr/lib/csih/ but if you want > to "promote" it to src/winsup/ that's fine. When/if that happens, we'll > need to coordinate the release of cygwin-1.7.x-y and the new csih. Oh - that's why I didn't find it - csih renamed it to getVolInfo, and it is not part of the default PATH. And if we DO want to promote it, let's at least make sure --help gives something useful ;) $ volinfo --help ZwOpenFile(\??\C:\cygwin\home\eblake\zsh\--help) failed, c034 -- Eric Blake -- 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: volinfo (was: MVFS results)
Eric Blake byu.net> writes: > Oh - that's why I didn't find it - csih renamed it to getVolInfo, and it is > not part of the default PATH. Hmm. Maybe we should teach 'cygcheck -p' to do case-insensitive searches for the regex; this would have turned up csih for 'cygcheck -c volinfo', instead of silence. After all, depending on your mount and windows case sensitivity settings, some users can already directly run /usr/lib/csih/getvolinfo. -- Eric Blake -- 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: perl threads on 2008 R2 64bit = crash ( was: perl 5.10 threads on 1.5.25 = instant crash )
Corinna Vinschen wrote:
> On Jul 15 20:32, Dave Korn wrote:
>> Yes. That's why I said "examine the SEH chain", not "look at the call
>> stack". I reckoned that doing so might provide any insight into why the
>> myfault was not invoked. For instance, you might see something hooked into
>> the SEH chain ahead of Cygwin's handler and start to look at what it was and
>> where it came from; and if not, you would be able to infer that the SEH chain
>> was not being invoked and start looking at the various SEH security
>> enhancements in recent windows versions and wondering which one might make it
>> think it shouldn't call handlers from a non-registered stack-based SEH
>> registration record.
>
> I'm not opposed to get some help with this stuff...
I don't have 2k8 to test it on myself, but if you can get this reproducing
under the debugger, then use a command like
(gdb) list 'verifyable_object_isvalid(void const*, long, void*, void*, void*)'
94paranoid_printf ("threadcount %d. unlocked",
MT_INTERFACE->threadcount);
95 }
96
97 static inline verifyable_object_state
98 verifyable_object_isvalid (void const *objectptr, long magic, void
*static_ptr1,
99 void *static_ptr2, void *static_ptr3)
100 {
101 myfault efault;
102 /* Check for NULL pointer specifically since it is a cheap test and
avoids the
103 overhead of setting up the fault handler. */
(gdb)
104 if (!objectptr || efault.faulted ())
105 return INVALID_OBJECT;
106
107 verifyable_object **object = (verifyable_object **) objectptr;
108
109 if ((static_ptr1 && *object == static_ptr1) ||
110 (static_ptr2 && *object == static_ptr2) ||
111 (static_ptr3 && *object == static_ptr3))
112 return VALID_STATIC_OBJECT;
113 if ((*object)->magic != magic)
(gdb)
check which line number the dereference is on, in my case 113, so set a
breakpoint there
(gdb) b 113 if ((*object) == 0)
No symbol "object" in current context.
(gdb)
Ah, that's bad. It might work on a DLL compiled with -O0 -g, but here we
have a problem that the function gets inlined everywhere it's called. So
instead I set an unconditional breakpoint there and let it run until I hit it:
(gdb) b 113
Breakpoint 3 at 0x610d0411: file /gnu/winsup/src/winsup/cygwin/thread.cc, line
113. (18 locations)
(gdb) disa 2
(gdb) c
Continuing.
Because that breakpoint is set on every inlined instance of the function,
you might need to continue it several times, until it hits the particular
inlined instance in the particular function that is blowing up. Let us say
for the sake of argument that it was in pthread_key_create;
Breakpoint 3, pthread_key_create (key=0x43b0a0,
destructor=0x408e00 )
at /gnu/winsup/src/winsup/cygwin/thread.cc:113
113 if ((*object)->magic != magic)
... so I check the disassembly to see what register was being dereferenced for
comparison to the magic number:
(gdb) disass $eip $eip+10
Dump of assembler code from 0x610d7c46 to 0x610d7c50:
0x610d7c46 :mov(%esi),%eax
0x610d7c48 :cmpl $0xdf0df047,0x4(%eax)
0x610d7c4f :jne0x610d7c06
End of assembler dump.
(gdb)
... and set a breakpoint using the assembler parameters:
(gdb) b *0x610d7c48 if ($eax == 0)
Breakpoint 5 at 0x610d7c48: file /gnu/winsup/src/winsup/cygwin/thread.cc, line
113.
(gdb) disa 3
(gdb) c
Continuing.
Caught integer 2.
Program exited normally.
(gdb)
... and then my program exited normally, because it didn't ever try to
dereference a NULL pointer at that point. But, if the breakpoint did trip,
you could then examine the SEH chain. The SEH chain head lives at [fs:0], so
look up the base of the $fs selector using "info w32 selector"
(gdb) info w32 selectors
Undefined info w32 command: "selectors". Try "help info w32".
(gdb) info w32 selector
Selector $cs
0x01b: base=0x limit=0x 32-bit Code (Exec/Read, N.Conf)
Priviledge level = 3. Page granular.
Selector $ds
0x023: base=0x limit=0x 32-bit Data (Read/Write, Exp-up)
Priviledge level = 3. Page granular.
Selector $es
0x023: base=0x limit=0x 32-bit Data (Read/Write, Exp-up)
Priviledge level = 3. Page granular.
Selector $ss
0x023: base=0x limit=0x 32-bit Data (Read/Write, Exp-up)
Priviledge level = 3. Page granular.
Selector $fs
0x038: base=0x7ffde000 limit=0x0fff 32-bit Data (Read/Write, Exp-up)
Priviledge level = 3. Byte granular.
Selector $gs
0x000: Segment not present
(gdb)
... get the head pointer:
(gdb) x/xw 0x7ffde000
0x7ffde000: 0x0022ce68
... on the stack, as you might expect, and walk the chain, first word of each
record is the 'next' pointer, second is the handler function:
(gdb) x/2xw 0x0022ce68
0x22ce68: 0x0022ffe0 0x61028770
(gdb) x 0x61028770
0x61028770 <_ZN7_cygtls17handle_exceptionsEP17_EXCEPTION_RECORDP15_exception_lis
tP8_CONTEXTPv>: 0x57e58955
(gdb) x/2xw 0x0022ffe0
0x22ffe0: 0x
How to activate new fstab mount points under 1.7?
Having read: http://cygwin.com/1.7/cygwin-ug-net/using.html#mount-table I'm still at a loss how to activate newly added mount points from fstab? The standard Unix paradigm would be mount -a or mount but none of these work. The only way I've found is to restart the cygwin prompt which is obviously not ideal. Any I missing something or has this functionality just been overlooked? Regards Steve -- 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] unzip is OK, zip is not
On Wed, Jul 15, 2009 at 02:46:57PM -0400, Charles Wilson wrote: >Jim Reisert AD1C wrote: >> I have been running Cygwin 1.7 for a while. >> >> There is one annoying problem, when ZIP/UNZIP were installed, I have >> an unzip.exe executable, but no zip.exe executable. This doesn't >> matter in *sh shells, but does matter when I'm using Cygwin in a "DOS" >> window: >> >>c:\>which unzip >>unzip is an external : C:\Cygwin\bin\unzip.exe >> >>c:\>which zip >>zip is an unknown command >> >> Is there a way to fix this (other than by making another copy of the file)? > >Known packaging error in zip-3.0-10. I haven't had a chance to respin >and push zip-3.0-11 yet. > >Just 'mv zip zip.exe' for now. This is an example of the recently discussed: http://cygwin.com/ml/cygwin/2009-07/msg00467.html http://cygwin.com/ml/cygwin/2009-07/msg00460.html And, it was specifically what I was thinking of when I wrote the last paragraph of: http://cygwin.com/ml/cygwin/2009-07/msg00465.html cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How to activate new fstab mount points under 1.7?
On Wed, Jul 15, 2009 at 09:33:20PM +0100, Steven Hartland wrote: >Having read: >http://cygwin.com/1.7/cygwin-ug-net/using.html#mount-table > >I'm still at a loss how to activate newly added mount points >from fstab? > >The standard Unix paradigm would be mount -a or mount >but none of these work. The only way I've found is to restart >the cygwin prompt which is obviously not ideal. > >Any I missing something or has this functionality just been >overlooked? Overlooked == not implemented. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: MVFS results
On Jul 15 19:42, Eric Blake wrote:
> New thread (gmane gave me grief at finding the old one, and anyways, I'm
> adding
> a couple new topics to the mix).
>
> $ attrib foo
>M:\foo
> $ attrib +r +s foo
> $ attrib foo
> R M:\foo
> $ rm foo
> rm: remove write-protected regular empty file `foo'? y
> rm: cannot remove `foo': Permission denied
Huh? This looks like a bug in unlink. It's supposed to delete the
R/O flag prior to trying to delete the file. This should look like:
$ rm foo
rm: remove write-protected regular empty file `foo'? y
$
[...time passes...]
Hmm, no, it works fine on FAT. Why does removing the R/O flag not work
on MVFS?
[...more time passes...]
Eric, can you please change syscalls.cc, line 532 from
NtSetAttributesFile (fh, pc.file_attributes () & ~FILE_ATTRIBUTE_READONLY);
to
{
status = NtSetAttributesFile (fh, pc.file_attributes () &
~FILE_ATTRIBUTE_READONLY);
if (!NT_SUCCESS (status))
system_printf ("Blah: %p", status);
}
and see what status code is returned? Hmm, it's possible that
it doesn't print anything because it doesn't even reach this code.
This reminds me of the problem we have with remote HPFS filesystems,
which have to be opened with GENERIC_WRITE rather than with
FILE_WRITE_ATTRIBUTES when trying to write timestamps. See below.
> $ attrib -r foo
> $ rm foo
>
> Just as we suspected, MVFS doesn't support DOS attributes, which also
> interferes with deletion abilities (I can also use 'chmod a+w' instead
> of 'attrib -r' to get deletion to work).
This is really weird. The R/O flag *is* supported, the SYSTEM flag
isn't. I assume the HIDDEN flag isn't either, but that's a minor
problem.
The fact that the SYSTEM flag is not supported would be easily worked
around by always creating winsymlinks on MVFS. However, this also
requires to find a fix for the above mysterious unlink problem.
> Another one that's been bothering me: cp -p can't preserve times when copying
> from a remote drive (I'm not sure if it is samba, NFS, or something else)
> over
> to MVFS, but touch can; also, copying from local to MVFS has no problems
> preserving times:
>
> $ echo > /tmp/bar
> $ cp -p /cygdrive/f/foo . # remote to MVFS
> $ ls -l /cygdrive/f/foo foo
> --+ 1 eblake Domain Users 925184 Nov 4 2004 cygdrive/f/foo
> -r--r--r-- 1 eblake Domain Users 925184 Jul 15 13:33 foo
> $ touch --ref cygdrive/f/foo foo
> $ ls -l /cygdrive/f/foo foo
> --+ 1 eblake Domain Users 925184 Nov 4 2004 /cygdrive/f/foo
> -r--r--r-- 1 eblake Domain Users 925184 Nov 4 2004 foo
> $ cp -p /tmp/bar bar# local to MVFS
> $ ll /tmp/bar bar
> -rw-r- 1 eblake Domain Users 1 Jul 15 13:26 /tmp/bar
> -rw-r--r-- 1 eblake Domain Users 1 Jul 15 13:26 bar
> $ touch bar
> $ ll /tmp/bar bar
> -rw-r- 1 eblake Domain Users 1 Jul 15 13:26 /tmp/bar
> -rw-r--r-- 1 eblake Domain Users 1 Jul 15 13:37 bar
>
> Do you need any straces for any of these actions?
Well, actual debugging and trying to find the problem would be preferred.
It's not fun to debug something only available by proxy.
As I said above, I assume that MVFS has a problem similar to what we
have for remote HPFS. It's not sufficient to set only the minimal
set of access flags in calls to NtCreateFile/NtOpenFile in some
circumstances. I can't tell where the problem is for cp -p since that
shouldn't call anything different from touch in terms of setting timestamps.
However, for the delete case I have a hunch that changing syscalls.cc,
line 457 from
access |= FILE_WRITE_ATTRIBUTES;
to
access |= GENERIC_WRITE;
will fix the problem on MVFS. Please try this and report back.
Once we have fixed this one, we can look into the timestamp problem.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: volinfo (was: MVFS results)
On Jul 15 20:23, Eric Blake wrote: > Charles Wilson cwilson.fastmail.fm> writes: > > > > > Eric Blake wrote: > > > Also, volinfo is such a helpful debug utility; should we go ahead and add > it to > > > the utils directory, and compile it alongside other tools like cygcheck > > > as > part > > > of the base package? > > > > It's already in the csih package, under /usr/lib/csih/ but if you want > > to "promote" it to src/winsup/ that's fine. When/if that happens, we'll > > need to coordinate the release of cygwin-1.7.x-y and the new csih. > > Oh - that's why I didn't find it - csih renamed it to getVolInfo, and it is > not > part of the default PATH. > > And if we DO want to promote it, Nah. It's ok as a herlper tool, but it's not worth to be put into winsup/utils. Maybe as part of cygcheck, but even if so, not now. > let's at least make sure --help gives > something useful ;) > > $ volinfo --help > ZwOpenFile(\??\C:\cygwin\home\eblake\zsh\--help) failed, c034 This *is* useful! C034 is STATUS_OBJECT_NAME_NOT_FOUND. What do you need more? It's always better to see an NT status code than a Win32 error code since the NT status codes are more detailed. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: volinfo (was: MVFS results)
On Wed, Jul 15, 2009 at 10:51:29PM +0200, Corinna Vinschen wrote: >On Jul 15 20:23, Eric Blake wrote: >> Charles Wilson cwilson.fastmail.fm> writes: >> >> > >> > Eric Blake wrote: >> > > Also, volinfo is such a helpful debug utility; should we go ahead and >> > > add >> it to >> > > the utils directory, and compile it alongside other tools like cygcheck >> > > as >> part >> > > of the base package? >> > >> > It's already in the csih package, under /usr/lib/csih/ but if you want >> > to "promote" it to src/winsup/ that's fine. When/if that happens, we'll >> > need to coordinate the release of cygwin-1.7.x-y and the new csih. >> >> Oh - that's why I didn't find it - csih renamed it to getVolInfo, and it is >> not >> part of the default PATH. >> >> And if we DO want to promote it, > >Nah. It's ok as a herlper tool, but it's not worth to be put into >winsup/utils. Maybe as part of cygcheck, but even if so, not now. Yeah, I was going to say that it should go into cygcheck myself. Hmm. I wonder if cygcheck should be a standalone utility so that we can update it without needing to update the DLL. Hmm. Deja vu. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: volinfo (was: MVFS results)
On Jul 15 16:54, Christopher Faylor wrote: > On Wed, Jul 15, 2009 at 10:51:29PM +0200, Corinna Vinschen wrote: > >On Jul 15 20:23, Eric Blake wrote: > >> Charles Wilson cwilson.fastmail.fm> writes: > >> > >> > > >> > Eric Blake wrote: > >> > > Also, volinfo is such a helpful debug utility; should we go ahead and > >> > > add > >> it to > >> > > the utils directory, and compile it alongside other tools like > >> > > cygcheck as > >> part > >> > > of the base package? > >> > > >> > It's already in the csih package, under /usr/lib/csih/ but if you want > >> > to "promote" it to src/winsup/ that's fine. When/if that happens, we'll > >> > need to coordinate the release of cygwin-1.7.x-y and the new csih. > >> > >> Oh - that's why I didn't find it - csih renamed it to getVolInfo, and it > >> is not > >> part of the default PATH. > >> > >> And if we DO want to promote it, > > > >Nah. It's ok as a herlper tool, but it's not worth to be put into > >winsup/utils. Maybe as part of cygcheck, but even if so, not now. > > Yeah, I was going to say that it should go into cygcheck myself. > > Hmm. I wonder if cygcheck should be a standalone utility so that we can > update it without needing to update the DLL. We could split out a cygwin-utils package at one point. But it's nothing I'd consider for 1.7.1. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl threads on 2008 R2 64bit = crash ( was: perl 5.10 threads on 1.5.25 = instant crash )
On Jul 15 21:42, Dave Korn wrote: > Corinna Vinschen wrote: > > On Jul 15 20:32, Dave Korn wrote: > >> Yes. That's why I said "examine the SEH chain", not "look at the call > >> stack". I reckoned that doing so might provide any insight into why the > >> myfault was not invoked. For instance, you might see something hooked into > >> the SEH chain ahead of Cygwin's handler and start to look at what it was > >> and > >> where it came from; and if not, you would be able to infer that the SEH > >> chain > >> was not being invoked and start looking at the various SEH security > >> enhancements in recent windows versions and wondering which one might make > >> it > >> think it shouldn't call handlers from a non-registered stack-based SEH > >> registration record. > > > > I'm not opposed to get some help with this stuff... > > I don't have 2k8 to test it on myself, but if you can get this reproducing > under the debugger, then use a command like > [...] Thanks for your help. I'm too tired right now to follow through. I'll look into it tomorrow. Thanks again, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: OpenSSH login failing thru PuTTY/plink
Jurriaan Kalkman wrote: > > any messages in the ssh logs on the servers? Any difference if you run > sshd with debug on on the servers? > This probably isn't what you mean, but -- I looked in /var/log/. sshd.log is length 0 and hasn't been touched in several weeks. The only file with a current modification timestamp is lastlog, which contains nothing of interest (mainly binary zeroes). To activate sshd debugging, I used the Windows Computer Management > Services panel and gave '-d 5' as a start parameter; started the sshd service, attempted a login, stopped the service, and looked at sshd.log. It was still zero length. So - what must I do to get ssh logging and useful sshd debugging information? Best regards, Chap -- View this message in context: http://www.nabble.com/OpenSSH-login-failing-thru-PuTTY-plink-tp24500041p24505901.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: perl threads on 2008 R2 64bit = crash ( was: perl 5.10 threads on 1.5.25 = instant crash )
- Original Message - From: "Dave Korn" (gdb) b 113 if ((*object) == 0) No symbol "object" in current context. (gdb) Ah, that's bad. It might work on a DLL compiled with -O0 -g, but here we have a problem that the function gets inlined everywhere it's called. So instead I set an unconditional breakpoint there and let it run until I hit it: From my experience last night you should be able to use something like:- b 113 if ( 0 == (**(verifyable_object **)objectptr) If not here at least it hits that break ~ 280 times before blowing up so setting a conditional on that occurrence should help. Unfortunately I'm currently testing a none threaded compile on the machine so cant check myself just now. -- 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 to activate new fstab mount points under 1.7?
- Original Message - From: "Christopher Faylor" Any I missing something or has this functionality just been overlooked? Overlooked == not implemented. ;-) Something that's planned? -- 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: perl threads on 2008 R2 64bit = crash ( was: perl 5.10 threads on 1.5.25 = instant crash )
Steven Hartland wrote: > > - Original Message - From: "Dave Korn" >> (gdb) b 113 if ((*object) == 0) >> No symbol "object" in current context. >> (gdb) >> >> Ah, that's bad. It might work on a DLL compiled with -O0 -g, but >> here we >> have a problem that the function gets inlined everywhere it's called. So >> instead I set an unconditional breakpoint there and let it run until I >> hit it: > > From my experience last night you should be able to use something like:- > b 113 if ( 0 == (**(verifyable_object **)objectptr) I did try it, but objectptr was out of scope as well. I'm using 1.7 and gcc-4.3.2, so it might well be that there's more inlining going on for me than for you, or changes in the debug info generation that account for it. > If not here at least it hits that break ~ 280 times before blowing up so > setting a conditional on that occurrence should help. :) That's the general idea! cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: MVFS results
Corinna Vinschen cygwin.com> writes:
> Eric, can you please change syscalls.cc, line 532 from
>
> NtSetAttributesFile (fh, pc.file_attributes () & ~FILE_ATTRIBUTE_READONLY);
>
> to
>
> {
> status = NtSetAttributesFile (fh, pc.file_attributes () &
~FILE_ATTRIBUTE_READONLY);
> if (!NT_SUCCESS (status))
> system_printf ("Blah: %p", status);
> }
>
> and see what status code is returned? Hmm, it's possible that
> it doesn't print anything because it doesn't even reach this code.
By itself, the Blah is never printed.
> > Just as we suspected, MVFS doesn't support DOS attributes, which also
> > interferes with deletion abilities (I can also use 'chmod a+w' instead
> > of 'attrib -r' to get deletion to work).
>
> This is really weird. The R/O flag *is* supported, the SYSTEM flag
> isn't. I assume the HIDDEN flag isn't either, but that's a minor
> problem.
You are correct, 'attrib +h' has no effect. I also suspect that the R/O flag
is being faked based on write permissions. That is, I can do:
$ attrib foo
M:\foo
$ chmod a-w foo
$ attrib foo
R M:\foo
>
> As I said above, I assume that MVFS has a problem similar to what we
> have for remote HPFS. It's not sufficient to set only the minimal
> set of access flags in calls to NtCreateFile/NtOpenFile in some
> circumstances. I can't tell where the problem is for cp -p since that
> shouldn't call anything different from touch in terms of setting timestamps.
utimensat vs utimens?
>
> However, for the delete case I have a hunch that changing syscalls.cc,
> line 457 from
>
> access |= FILE_WRITE_ATTRIBUTES;
>
> to
>
> access |= GENERIC_WRITE;
Even with this added to the patch, it still doesn't seem to help. But
something weird is certainly going on:
Breakpoint 1, unlink_nt (p...@0x2247f4)
at ../../../../winsup/cygwin/syscalls.cc:445
445 unlink_nt (path_conv &pc)
(gdb) n
452 ACCESS_MASK access = DELETE;
(gdb)
456 if (pc.file_attributes () & FILE_ATTRIBUTE_READONLY)
(gdb)
457 access |= GENERIC_WRITE;
(gdb)
459 ULONG flags = FILE_OPEN_FOR_BACKUP_INTENT;
(gdb)
462 if (pc.is_rep_symlink ())
(gdb)
465 pc.get_object_attr (attr, sec_none_nih);
(gdb)
472 bin_status bin_stat = dont_move;
(gdb)
473 status = NtOpenFile (&fh, access, &attr, &io, FILE_SHARE_DELETE,
flags);
(gdb) p fh
$1 = (HANDLE) 0x2247f4
(gdb) p access
$2 = 1073807360
(gdb) p attr
$3 = {Length = 24, RootDirectory = 0x0, ObjectName = 0x224814, Attributes = 0,
SecurityDescriptor = 0x0, SecurityQualityOfService = 0x0}
(gdb) p io
$4 = {Status = 0, Information = 0}
(gdb) p flags
$5 = 16384
(gdb) s
/home/eblake/coreutils/src/rm: cannot remove `foo': Permission denied
Program exited with code 01.
Basically, the NtOpenFile took over execution (I'm guessing that it triggered a
fault handler, which interfered with single stepping?). My next attempt:
(gdb) b 641
Breakpoint 2 at 0x610e2e3c: file ../../../../winsup/cygwin/syscalls.cc, line
641.
Breakpoint 2, unlink (
ourname=0x6b0038 "/project/fabt/foo")
at ../../../../winsup/cygwin/syscalls.cc:641
641 if (NT_SUCCESS (status))
(gdb) p/x status
$7 = 0xc022
(gdb) n
644 __seterrno_from_nt_status (status);
(gdb)
/home/eblake/coreutils/src/rm: cannot remove `foo': Permission denied
Program exited with code 01.
Now, even __seterrno_from_nt_status is running away.
Any ideas on what I should try next?
--
Eric Blake
--
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: Any solution to this build problem?
--- Jacob Jacobson wrote: > Perhaps this went unnoticed. Reposting it. I am still having > problems building cygwin dll. Has anyone seen this error? > >> > Getting close here. Apparently gets to the linking phase. Please help >> > with error below. >> > >> > [build$:618] (../src/configure --prefix=/c/home/wrk/cygwin/install -v; >> > make) >>> >>& make.out >> > [build$:619] tail make.out >> > >> > /c/home/wrk/cygwin/build/i686-pc-cygwin/winsup/cygwin/../../../../src/winsup/cygwin/lib/pseudo-reloc.c:33: >> > undefined reference to `___RUNTIME_PSEUDO_RELOC_LIST_END__' >> > collect2: ld returned 1 exit status >> > >> > make[3]: *** [cygwin0.dll] Error 1 >> > make[3]: Leaving directory >> > `/c/home/wrk/cygwin/build/i686-pc-cygwin/winsup/cygwin' >> > make[2]: *** [cygwin] Error 1 >> > make[2]: Leaving directory >> > `/c/home/wrk/cygwin/build/i686-pc-cygwin/winsup' >> > make[1]: *** [all-target-winsup] Error 2 >> > make[1]: Leaving directory `/c/home/wrk/cygwin/build' >> > make: *** [all] Error 2 >> > [build$:620] Try to remove the build directory to configure and make again from the beginning. -- 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: perl threads on 2008 R2 64bit = crash ( was: perl 5.10 threads on 1.5.25 = instant crash )
2009/7/15 Steven Hartland: > This may or may not help: > > According to VC++ debugger it always dies with: > Unhandled exception at 0x610d089d in perl.exe: 0xC005: Access violation > reading location 0x0004. > > According to gdb 0x610d089d = thread.cc:113 Thanks! This looks like almost certainly a simple perl bug. Threads was Jerry Heddens working arena lately, but there are complicated things going in core. If it's easily reproducible best would be to start with a debugging perl and break at the point which tries to read from 0x4. BTW: I thought about adding -debug packages in general (to cygport) as with fedora, but got distracted somewhere. -- Reini Urban -- 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: perl threads on 2008 R2 64bit = crash ( was: perl 5.10 threads on 1.5.25 = instant crash )
2009/7/16 Reini Urban: > 2009/7/15 Steven Hartland: >> This may or may not help: >> >> According to VC++ debugger it always dies with: >> Unhandled exception at 0x610d089d in perl.exe: 0xC005: Access violation >> reading location 0x0004. >> >> According to gdb 0x610d089d = thread.cc:113 > > Thanks! > > This looks like almost certainly a simple perl bug. Threads was Jerry Heddens > working arena lately, but there are complicated things going in core. > If it's easily reproducible best would be to start with a debugging perl > and break at the point which tries to read from 0x4. Sorry, cannot reproduce either with the following perls: 5.8.5 5.8.5d 5.8.6 5.8.8 5.10.0 5.10.0d 5.11.0d under cygwin-1.5.25 and XP SP2 and neither under latest cygwin-1.7.0 -- 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: perl threads on 2008 R2 64bit = crash ( was: perl 5.10 threads on 1.5.25 = instant crash )
On Thu, Jul 16, 2009 at 04:07:23AM +0200, Reini Urban wrote: >2009/7/15 Steven Hartland: >> This may or may not help: >> >> According to VC++ debugger it always dies with: >> Unhandled exception at 0x610d089d in perl.exe: 0xC005: Access violation >> reading location 0x0004. >> >> According to gdb 0x610d089d = thread.cc:113 > >Thanks! > >This looks like almost certainly a simple perl bug. Threads was Jerry Heddens >working arena lately, but there are complicated things going in core. >If it's easily reproducible best would be to start with a debugging perl >and break at the point which tries to read from 0x4. I can reproduce it. It looks like perl (or more likely Windows) is adding something extra to the SEH chain. I'm too tired to track it down any further tonight though. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
build/i686-pc-cygwin/winsup make check
Just to point out (as probably I'll solve it myself later): $ tail make_check_outerr make[1]: Entering directory `/opt/build/i686-pc-cygwin/winsup/cygwin' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/opt/build/i686-pc-cygwin/winsup/cygwin' make[1]: Entering directory `/opt/build/i686-pc-cygwin/winsup/testsuite' gcc -L/opt/build/i686-pc-cygwin/winsup -L/opt/build/i686-pc-cygwin/winsup/testsu ite -L/opt/build/i686-pc-cygwin/winsup/w32api/lib -isystem /opt/src/winsup/inclu de -isystem /opt/src/winsup/testsuite/include -isystem /opt/src/winsup/w32api/in clude -B/opt/build/i686-pc-cygwin/newlib/ -isystem /opt/build/i686-pc-cygwin/new lib/targ-include -isystem /opt/src/newlib/libc/include-I/usr/lib/gcc/i686-pc -cygwin/4.3.2/include -mno-cygwin -I/opt/src/winsup/w32api/include -o cygrun.o -c /opt/src/winsup/testsuite/cygrun.c gcc: The -mno-cygwin flag has been removed; use a mingw-targeted cross-compiler. make[1]: *** [cygrun.o] Error 1 make[1]: Leaving directory `/opt/build/i686-pc-cygwin/winsup/testsuite' make: *** [check] 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
