Re: [1.7] Updated: dash-0.5.5.1-2; Obsolete: ash
On Jul 14 16:09, Corinna Vinschen wrote: On Jul 14 06:41, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 7/14/2009 6:29 AM: The package dash has been upgraded to 0.5.5.1-2 for those using cygwin 1.7, simultaneously replacing dash-0.5.5.1-1 and ash-20040127-4. The ash package is now obsolete; ash.exe is provided by the dash package. The following packages should update their setup.hint to refer to dash rather than ash: fetchmail rebase I changed the setup.hint files on sourceware. Jason, please change that in your local files. Here's another problem, even though it's a small one. If you don't start ash, but dash, then rebaseall refuses to run with the usual message: rebaseall: only ash processes are allowed during rebasing Exit all Cygwin processes and stop all Cygwin services. Execute ash from Start/Run... or a cmd or command window. Execute '/bin/rebaseall' from ash. I guess the code should be changed to accept ash and dash. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [1.7] Updated: dash-0.5.5.1-2; Obsolete: ash
On Wed, Jul 15, 2009 at 10:29:31AM +0200, Corinna Vinschen wrote: On Jul 14 16:09, Corinna Vinschen wrote: On Jul 14 06:41, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 7/14/2009 6:29 AM: The package dash has been upgraded to 0.5.5.1-2 for those using cygwin 1.7, simultaneously replacing dash-0.5.5.1-1 and ash-20040127-4. The ash package is now obsolete; ash.exe is provided by the dash package. The following packages should update their setup.hint to refer to dash rather than ash: fetchmail rebase I changed the setup.hint files on sourceware. Jason, please change that in your local files. Here's another problem, even though it's a small one. If you don't start ash, but dash, then rebaseall refuses to run with the usual message: rebaseall: only ash processes are allowed during rebasing Exit all Cygwin processes and stop all Cygwin services. Execute ash from Start/Run... or a cmd or command window. Execute '/bin/rebaseall' from ash. I guess the code should be changed to accept ash and dash. dash it all! cgf
[ITP] ruby 1.9.1
I am interested to begin maintaining a package for Ruby 1.9.1. I wanted to ask some questions about this though. 1.) How should Ruby 1.9 be packaged? Explanation: Right now there are packages for Ruby 1.8.7; if we follow the pattern of various Linux distros, Ruby 1.9.1 would go in as a separate package named perhaps ruby19 instead of the default ruby, which would continue to represent the 1.8.x branch. 2.) Is there a current maintainer for the ruby package that I should get in touch with to prevent trampling on their toes? If not, I am more than willing to take on maintenance of the ruby package overall. Thanks, -- James Thompson Plain Programs New Orleans, LA P: (502) 619.0353 E: ja...@plainprograms.com W: www.plainprograms.com
Re: [ITP] ruby 1.9.1
On Jul 15 09:55, James Thompson wrote: I am interested to begin maintaining a package for Ruby 1.9.1. I wanted to ask some questions about this though. 1.) How should Ruby 1.9 be packaged? Explanation: Right now there are packages for Ruby 1.8.7; if we follow the pattern of various Linux distros, Ruby 1.9.1 would go in as a separate package named perhaps ruby19 instead of the default ruby, which would continue to represent the 1.8.x branch. 2.) Is there a current maintainer for the ruby package that I should get in touch with to prevent trampling on their toes? If not, I am more than willing to take on maintenance of the ruby package overall. I'm the current ruby maintainer. The maintainer list is here: http://cygwin.com/cygwin-pkg-maint I'm busy enough with other stuff, so, if you really want to take over maintainership, I have no problems with that, provided the new ruby package is for Cygwin 1.7 only, and you actually *port* it to Cygwin 1.7 (IPv6, long pathname support, you name it). Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] ruby 1.9.1
I'm definitely interested in taking up maintenance since I have a real need. Right now my concern is to get Ruby 1.9 available for the 1.5 branch which is the current stable that I'm using in production. Once that is out of the way I would definitely be willing to work on getting Ruby 1.8 and 1.9 working with Cygwin 1.7. I am getting close to having Ruby 1.9 ready to go on Cygwin 1.5 so I could start looking at Cygwin 1.7 this week. Is there a timeline for the actual release of Cygwin 1.7? On Wed, Jul 15, 2009 at 12:38 PM, Corinna Vinschencorinna-cyg...@cygwin.com wrote: On Jul 15 09:55, James Thompson wrote: I am interested to begin maintaining a package for Ruby 1.9.1. I wanted to ask some questions about this though. 1.) How should Ruby 1.9 be packaged? Explanation: Right now there are packages for Ruby 1.8.7; if we follow the pattern of various Linux distros, Ruby 1.9.1 would go in as a separate package named perhaps ruby19 instead of the default ruby, which would continue to represent the 1.8.x branch. 2.) Is there a current maintainer for the ruby package that I should get in touch with to prevent trampling on their toes? If not, I am more than willing to take on maintenance of the ruby package overall. I'm the current ruby maintainer. The maintainer list is here: http://cygwin.com/cygwin-pkg-maint I'm busy enough with other stuff, so, if you really want to take over maintainership, I have no problems with that, provided the new ruby package is for Cygwin 1.7 only, and you actually *port* it to Cygwin 1.7 (IPv6, long pathname support, you name it). Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] ruby 1.9.1
On Jul 15 13:11, James Thompson wrote: I'm definitely interested in taking up maintenance since I have a real need. Right now my concern is to get Ruby 1.9 available for the 1.5 branch which is the current stable that I'm using in production. Once 1.5 is dead. From my POV it's not worth to add any new packages. As soon as 1.7 goes live, the 1.5 release area goes into frozen mode. that is out of the way I would definitely be willing to work on getting Ruby 1.8 and 1.9 working with Cygwin 1.7. I am getting close to having Ruby 1.9 ready to go on Cygwin 1.5 so I could start looking at Cygwin 1.7 this week. Is there a timeline for the actual release of Cygwin 1.7? We have still a couple of problems but we're still heading for a two weeks timeframe. No guarantee, but still... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Often lose window decoration when restore from standby
On 13/07/2009 20:35, KARR, DAVID (ATTCINW) wrote: I'm using Cygwin 1.5.25 on WinXPSP2, along with Cygwin-built GNU Emacs 23.0.92.1. I run startxwin.bat on system startup. After it comes up, I run Emacs, and I get a good window with normal Windows-based window decorations. My Windows shortcut does this: C:\cygwin\bin\rxvt.exe -geometry 1x1 -ls -cd c:\cygwin\home\dk068x -e /usr/bin/bash -l -c /usr/bin/emacs I often find that after I restore from Standby, I see an odd symptom, in that the Emacs window no longer has any window decorations. The edge of the Emacs menu bar is the edge of the window. If I kill the Emacs process and start it again from the shortcut, even that doesn't fix it. What fixes it is killing the Xwin process, rerunning startxwin.bat, and then rerunning Emacs. Very interesting, but I'm afraid I can't reproduce this problem. Does this only affect emacs? or all X windows? This might be caused by the internal WM thread not being able to talk to the server anymore after a resume, but I would have thought that would cause the whole process to terminate... Can I see a /var/log/Xwin.0.log, please? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: 1.5.25: Problem with XtAppAddWorkProc and OptionMenu
On 10/07/2009 09:19, Wakker, P.H. (Pieter) wrote: I am running CYGWIN 1.5.25 on Windows XP pack 2. I have a XWindows graphics program that uses several XmOptionMenu widgets. The problem is that whenever the user clicks frequently (sometimes a double-click is enough) on these OptionMenu's the program crashes with a segmentation error. This behaviour is not noticeable with the same program on HP-UX. I'm not sure what this means you tried? Building the same client program on HP-UX (which possibly has a completely different lesstif/motif library)? I am dubious this is a cygwin-specific issue (Cygwin's lesstif only has a couple of minor patches to the configury to make it build) I reproduced the problem in the test program below. It seems as if the combination of the WorkProc and the OptionMenu causes the problem. If I remove the XtAppAddWorkProc statement there is no problem, but the only widget that causes the crash is an OptionMenu (for example with a PushButton I can't reproduce the crash). Another thing I noticed is that when I reduce the number of microseconds in the usleep command, I have to click faster to make the program crash. It seems as if there is a relationship with how long the program is busy in the WorkProc. In the actual program the usleep is replaced by something useful of course. Thanks for the test-case. With a bit of frantic clicking, I can reproduce the problem with a crash in XmInputInGadget(). Unfortunately I have no clue about lesstif internals so you might get more help via [1] [1] http://www.lesstif.org/bugs.html -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
src/winsup/cygwin ChangeLog path.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2009-07-15 13:27:35 Modified files: winsup/cygwin : ChangeLog path.cc Log message: * path.cc (cwdstuff::set): Only fix up UNC path in win32 so as not to overwrite incoming path. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4567r2=1.4568 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/path.cc.diff?cvsroot=srcr1=1.553r2=1.554
src/winsup/cygwin ChangeLog fhandler_netdrive.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2009-07-15 14:31:51 Modified files: winsup/cygwin : ChangeLog fhandler_netdrive.cc Log message: * fhandler_netdrive.cc (fhandler_netdrive::readdir): Remove useless alloca. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4568r2=1.4569 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_netdrive.cc.diff?cvsroot=srcr1=1.23r2=1.24
Re: ls and wildcards
Am 14.07.2009, 17:47 Uhr, schrieb Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com: 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 cgf-use-the-mailinglist-ple...@cygwin.com: 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 stdio.h
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 cygwin-ow...@cygwin.com
To: cygwin@cygwin.com 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 stdio.h
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 corinna-cygwin at 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 corinna-cygwin at 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 corinna-cygwin at 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 12 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
cgf-use...
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 stdio.h
#include errno.h
#include pthread.h
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
cgf-use...
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 stdio.h
#include errno.h
#include pthread.h
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: CCase Serial Number : 36984713 Max Filenamelength : 255 Filesystemname : MVFS 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 !symlink~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 stdio.h
#include errno.h
#include pthread.h
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 corinna-cygwin at 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: CCase Serial Number : 36984713 Max Filenamelength : 255 Filesystemname : MVFS 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 !symlink~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 k377 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 corinna-cygwin at 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, jjreis...@alum.mit.edu, 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: SLDAT10 Serial Number : 1414974143 Max Filenamelength : 255 Filesystemname : NTFS 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 : NTFS 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 c...@pobox.com 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 12 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 cygwin at 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 ebb9 at 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 eh_globals_dtor)
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 pthread_key_create+214:mov(%esi),%eax
0x610d7c48 pthread_key_create+216:cmpl $0xdf0df047,0x4(%eax)
0x610d7c4f pthread_key_create+223:jne0x610d7c06 pthread_key_create+15
0
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:
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 target 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 target 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 cygwin at 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 cygwin at 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 cygwin at 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 corinna-cygwin at 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
