Re: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
Greetings, John Carey! > After a call to SetCurrentDirectory(), I have seen occasional (< 5%) > failures of CreatePipe() with code ERROR_INVALID_HANDLE. I have also seen > failure of Cygwin signal handling because the signal handling pipe has > mysteriously closed. Seems like it was discussed a short while ago. mid:008101cb3597$a75069f0$f5f13d...@gmail.com -- WBR, Andrey Repin (anrdae...@freemail.ru) 10.08.2010, <12:56> Sorry for my terrible english... -- 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
Incomplete installation of subversion
Hi! I have a reasonably up to date cygwin installation (did an update a week ago or so). Today I run the latest setup (v2.708). In Pending I saw a few libX packages and minttty 0.8.1. Then I selected subversion for install. On "Next" I got a dialog saying that subversion depended on additional packages. I clicked... I don't really remember what, I guess it was OK or Yes. Then it installed subversion and the updates. But when I started mintty and entered svn, I got this: $ svn /usr/bin/svn.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory I started Setup again, and now under Pending I see: - wouldn't it be wonderful to be able to copy paste text from dialogs? - crypt - libgdm4 - libopenldap2_3_0 - libopenssl098 - libpq5 - libproxy0 - minires So what did I do wrong? I am waiting with the install of the above packages in case you have a question about the current state of my system. Regards, David -- 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.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
On Aug 10 00:19, John Carey wrote:
> After a call to SetCurrentDirectory(), I have seen occasional (< 5%)
> failures of CreatePipe() with code ERROR_INVALID_HANDLE. I have also
> seen failure of Cygwin signal handling because the signal handling
> pipe has mysteriously closed.
Why on earth are you calling SetCurrentDirectory in a Cygwin application?
> I believe that both symptoms are due to this code in
> winsup/cygwin/path.cc, which as the comments state, is not
> thread-safe:
>
> /* Workaround a problem in Vista/Longhorn which fails in subsequent
> calls to CreateFile with ERROR_INVALID_HANDLE if the handle in
> CurrentDirectoryHandle changes without calling SetCurrentDirectory,
> and the filename given to CreateFile is a relative path. It looks
> like Vista stores a copy of the CWD handle in some other undocumented
> place. The NtClose/DuplicateHandle reuses the original handle for
> the copy of the new handle and the next CreateFile works.
> Note that this is not thread-safe (yet?) */
> NtClose (*phdl);
> if (DuplicateHandle (GetCurrentProcess (), h, GetCurrentProcess (),
> phdl,
>0, TRUE, DUPLICATE_SAME_ACCESS))
> NtClose (h);
you missed the
else
*phdl = h;
> If another thread allocates a handle between the NtClose and the
> Duplicate, then the handle value is not preserved, and strange effects
> may result.
Note that phdl is a pointer to the handle storage within the PEB. Since
the PEB is locked (RtlAcquirePebLock/RtlReleasePebLock) and Cygwin's
cwdstuff::set as well as the native SetCurrentDirectory both lock the
PEB before writing the CurDir content, there's no chance for a
concurrency issue between those functions.
Also note that the old content of *phdl is *always* overwritten, either
by the result of the DuplicateHandle call, or by the value of CreateFile.
> Presumably the issues mentioned in the source comment may
> also occur, but what I have seen myself is a subsequent call to
> SetCurrentDirectory() closing, not the current directory handle, but
> the handle that was allocated by the other thread.
>
> Specifically, dll_crt0_1() calls sigproc_init(), then cwdstuff::set(),
> and finally wait_for_sigthread(). The function sigproc_init() creates
> the signal handling thread, which creates the signal handling pipe as
> one of its very first actions, then sets the event for which
> wait_for_sigthread() waits. I think this scenario happens:
>
> 1. main thread: cwdstuff::set(): NtClose().
>
> 2. signal handling thread: CreatePipe() opens a handle to
> '\Device\NamedPipe\' and stores it in a global variable (because
> this is the first call to CreatePipe()).
>
> 3. main thread: cwdstuff::set(): DuplicateHandle().
>
> In this case, the current directory handle value has changed, which is
> not the intend of the NtClose-Duplicate sequence.
No, that's not intended. However, the code just *tries* to preserve the
handle value, but it does not rely on it. The NtClose is safe because
the handle is the actual CWD handle at the time of the call and the PEB
is locked. The DuplicateHandle call just uses the phdl storage to store
the new handle value, but it *never* tests if the new handle value is
identical to the old one. So, if all works well, it's the same handle
value as before. If not, *shrug*.
> CreateFile to fail with ERROR_INVALID_HANDLE as mentioned in the
> source comments, but I have not seen that. I think that the
I have. You can easily test this as well on Vista and W7. Just drop
the DuplicateHandle call and simply store h in *phdl. Then create a
testcase:
chdir ("/");
h = CreateFile ("foobar", ...);
if (h == INVALID_HANDLE_VALUE) printf ("%lu\n", GetLastError());
> CreatePipe() failures I have seen are triggered when
> SetCurrentDirectory() closes the handle to '\Device\NamedPipe\',
> thinking that it is the current directory handle. After that,
> CreatePipe() will fail with ERROR_INVALID_HANDLE.
As mentioned above, calling SetCurrentDirectory in a Cygwin application
is not correct at all. All relative path handling in Cygwin relies on
the fact that a Cygwin application calls the chdir function. If you're
calling SetCurrentDirectory you're on your own.
And then again, note that the call to SetCurrentDirectory will not
overwrite the PEB value of the cwd handle until the cwdstuff::set
function has called RtlReleasePebLock.
> I think this other scenario also happens:
>
> 1. signal handling thread: CreatePipe() opens a handle to
> '\Device\NamedPipe\' (because it is the first call to CreatePipe()).
>
> 2. main thread: cwdstuff::set(): NtClose().
>
> 3. signal handling thread: CreatePipe() opens pipe handles.
>
> 4. main thread: cwdstuff::set(): DuplicateHandle().
>
> In this case it is Cygwin signal handling that is sabotaged by
> subsequent calls to SetCurrentDirectory(), because they close one of
Re: sed: --binary flag is undocumented
On Aug 9 16:41, Carles Cufi wrote: > Hi there, > > I just found out in the IRC channel that to avoid trouble with > cygwin's sed turning \r\n into \n one needs to pass the "--binary" > flag. But this is not documented in the sed man pages, I was wondering > if it should be. I think this is an upstream decision. You could ask the sed developers. 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: Incomplete installation of subversion
On 10 August 2010 12:41, David Balažic wrote: > I have a reasonably up to date cygwin installation (did an update a > week ago or so). > Today I run the latest setup (v2.708). In Pending I saw a few libX > packages and minttty 0.8.1. > > Then I selected subversion for install. > On "Next" I got a dialog saying that subversion depended on additional > packages. > I clicked... I don't really remember what, I guess it was OK or Yes. > > Then it installed subversion and the updates. > > But when I started mintty and entered svn, I got this: > > $ svn > /usr/bin/svn.exe: error while loading shared libraries: ?: cannot open > shared object file: No such file or directory > > I started Setup again, and now under Pending I see: > - wouldn't it be wonderful to be able to copy paste text from dialogs? > - crypt > - libgdm4 > - libopenldap2_3_0 > - libopenssl098 > - libpq5 > - libproxy0 > - minires > > So what did I do wrong? Nothing. It's a bug in the resolver behind the "Unmet dependencies" page: it doesn't add indirect dependencies. This is fixed in CVS, to be rolled out soon. > I am waiting with the install of the above packages in case you have a > question about the current state of my system. Thanks very much, but hopefully we've got this one cornered already. Andy -- 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: Fwd: BUG: ls generates faulty output from path with multiple spaces
On 08/10/2010 12:47 AM, James Arlow wrote: > Too bad you don't have a WEB BASED BUG TRACKING SYSTEM, > or you all wouldn't have gotten these two pointless emails To some degree, we have one: http://cygwin.com/ml/cygwin/ This mailing list IS our bug tracking system, and it DOES have a web archive. Meanwhile, no matter what system you set up on the web, I for one would still have the preferences set up to email me every change made in the web database. I work better on interrupts (such as email, whether it is sent directly by you or by the bot managing the web page) than on polling (randomly visiting the web page to see if someone has added a new bug since the last time I remembered to visit). -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
RE: Moses with Cygwin on Windows 7
I don't know if this might interest others, but I have found a thread explaining the UAC problem at http://social.answers.microsoft.com/Forums/en-US/vistasecurity/thread/67bfc4 b5-faff-4de4-be48-f395bf1c519d. There is an unofficial third-party software available from http://www.itknowledge24.com/ to create a white list so that specific programs can be exempted from UAC prompts. We don't have a computer with Windows 7 yet, so can't test it out, but I like the idea. Llio -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Eliot Moss Sent: 08 August 2010 00:34 To: cbs...@bangor.ac.uk Cc: l...@testun.co.uk; cygwin@cygwin.com Subject: Re: Moses with Cygwin on Windows 7 On 8/7/2010 5:23 PM, cbs...@bangor.ac.uk wrote: > many thanks for your reply. On why we need cygwin: the language model we use is IRSTLM. The native > windows build of Moses does not currently use IRSTLM LMs. I know next to nothing about Moses, so I'll just trust you on this one! > I have been reading up a bit about debasing DLLs, and I gather from > http://www.codeproject.com/KB/DLL/RebaseDll.aspx that the purpose is to avoid either two or more > DLLs using the same preferred base addresses, or the overheads of relocation. However, on > http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/bac7e300-f3df -4087-9c4b-847880d625ad, > it is suggested that from Vista onwards, it is better to leave this to the operating systems's ASLR > (Address space layout randomization) in order to help defeat a ?return-to-libc? attack. Do you agree > with this? If it is still necessary to do a rebase, what does your script do that rebaseall doesn't? The problem is that the address space randomization interferes with how cygwin support fork(). Suppose a parent process maps library A at address X, but does not map library B at all. Then suppose a forked process is not yet using library A, and ends up mapping library B at an address that overlaps X. Then the child reaches a point where it needs to use library A. The implementation of cygwin requires that if a parent and child use the same library, it must be at the same address. Therefore the child's mapping attempt will block. That gives a sense of the scenario. That may not be the exact case, but it's like that. Basically, we need to guarantee that all cygwin dlls map to different preferred places. Yes, this defeats the OS attempt to defeat a security attack. My script finds and rebases every dll file that cygwin 'find' can locate, while rebaseall only does certain directories. For me, the difference lies in (at least) some perl-related dlls that are not where rebaseall looks. Another important thing is that the distance between preferred locations needs to be a little bigger than the default for rebase, on Vista (and Windows 7). This is an obscure thing that Corinna found a while back and took me quite a while to locate in old email threads, but before I set that parameter, rebasing did not work right for me and after adding that it did. Maybe they have changed the default by now, but I don't think so. > Re UAC prompts: this does look annoying but corporate security regulations may prevent us from > turning it off completely. Is there some way to turn it off for individual programs without using > third-party software? That lies outside my expertise. I just turned it off. Best wishes -- Eliot Moss -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ADMINISTRIVIA] Experimental block of some email with raw addresses
I've just instituted a block of email which contains certain email addresses like "cygwin AT ...", "cygwin-owner AT ..." and others. Since I'm using spamassassin to do that, I suspect that the bounce message won't be really clear and it will increase my administrative burden but I thought I'd give it a try since it was relatively easy to do. 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
extending a VS python with cygwin
summary: I've got a version of python that I need for other purposes. I'm trying to build duplicity to use with that python. I'm getting m...@cygwinbox ~/bin/duplicity-0.6.09$ python setup.py install ... > error: Python was built with Visual Studio 2003; > extensions must be built with a compiler than can generate > compatible binaries. Visual Studio 2003 was not found on this > system. If you have Cygwin installed, you can try compiling with > MingW32, by passing "-c mingw32" to setup.py. How to do this? details: I mostly run linux, and I've been using python-based `duplicity` http://duplicity.nongnu.org/ to back that up. I've got an older winxp box (SP3, uptodate with WU) which I keep mostly to run ArcGIS, which has happily run many versions of cygwin (which I keep uptodate) over the years. I'd like to be able to restore my linux home to my cygwin home for the rare occasions when I need to use the winxp box. To do that, I'd like to install duplicity on the cygwin box. That install process (best described by the somewhat downlevel http://blog.khorun.com/2008/09/using-duplicity-on-windows-under-cygwin.html ) works for the install of the prerequisite GnuPGInterface and boto python modules (process=[download tarball, tar xfz, python setup.py install]) but fails for the install of duplicity itself, with the error: m...@cygwinbox ~/bin/duplicity-0.6.09$ python setup.py install ... > error: Python was built with Visual Studio 2003; Note that I'd cheerfully replace that version of python (the 2.5.2 that shipped with my ArcGIS 9.3), except that I use some ArcGIS extensions which seem to choke on other pythons :-( so I'd prefer to build against that if at all possible. > extensions must be built with a compiler than can generate > compatible binaries. Visual Studio 2003 was not found on this > system. If you have Cygwin installed, you can try compiling with > MingW32, by passing "-c mingw32" to setup.py. I tried to take the advice offered, but fail: m...@cygwinbox ~/bin/duplicity-0.6.09$ python -c mingw32 setup.py install > Traceback (most recent call last): > File "", line 1, in > NameError: name 'mingw32' is not defined m...@cygwinbox ~/bin/duplicity-0.6.09$ python setup.py -c mingw32 install > usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] >or: setup.py --help [cmd1 cmd2 ...] >or: setup.py --help-commands >or: setup.py cmd --help > error: option -c not recognized m...@cygwinbox ~/bin/duplicity-0.6.09$ python setup.py install -c mingw32 > usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] >or: setup.py --help [cmd1 cmd2 ...] >or: setup.py --help-commands >or: setup.py cmd --help > error: invalid command 'mingw32' What's the appropriate syntax here? Or how else should I fix this build problem? TIA, Tom Roche -- 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.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
Greetings to you as well! I did try to search, but was unsuccessful. Can you tell me the subject of one of the messages? Thanks, John Subject: Re: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set Greetings, John Carey! > After a call to SetCurrentDirectory(), I have seen occasional (< 5%) > failures of CreatePipe() with code ERROR_INVALID_HANDLE. I have also seen > failure of Cygwin signal handling because the signal handling pipe has > mysteriously closed. Seems like it was discussed a short while ago. mid:008101cb3597$a75069f0$f5f13d...@gmail.com -- WBR, Andrey Repin (anrdae...@freemail.ru) 10.08.2010, <12:56> Sorry for my terrible english... -- 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.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/08/2010 09:57, Andrey Repin wrote: > Greetings, John Carey! > >> After a call to SetCurrentDirectory(), I have seen occasional (< 5%) >> failures of CreatePipe() with code ERROR_INVALID_HANDLE. I have also seen >> failure of Cygwin signal handling because the signal handling pipe has >> mysteriously closed. > > Seems like it was discussed a short while ago. > mid:008101cb3597$a75069f0$f5f13d...@gmail.com Out of interest, what is that strange email address above supposed to refer to? - -- Al -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxhqb8ACgkQz4fTOFL/EDYW1gCePOArKa9PB8qhvNwaeQgtGfTt v6cAn1ixv/R9+BvWnD7vSgxY2sSkj9t6 =DTsS -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
[ANNOUNCEMENT] Update on status of make-3.82 release for cygwin
I wanted to let everyone know that I'm aware of the fact that make-3.82 has been released. However, given the number of reported problems in the make bugs mailing list, I don't plan on releasing a new version of GNU make until the dust has settled. That means no new version of make for at least a month. Also, given the ability to use more UNIX-like filenames in Cygwin 1.7.x, I'm contemplating not doing what I'd previously mentioned - using new changes in GNU make to allow MS-DOS file names like "c:\foo" in makefiles. I'll have to investigate just how much the Windows-isms in GNU make's code impact Cygwin make before I make a final determination. I may just decide to reenable the --ms-dos option as it used to be in the old days. Or, if that's too much work, I might just turn off special-case handling of c:\blah entirely - just like it is in make-3.81. FYI. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Update on status of make-3.82 release for cygwin
On 8/10/2010 10:54 AM, Christopher Faylor wrote:
I wanted to let everyone know that I'm aware of the fact that make-3.82
has been released. However, given the number of reported problems in
the make bugs mailing list, I don't plan on releasing a new version of
GNU make until the dust has settled. That means no new version of make
for at least a month.
Also, given the ability to use more UNIX-like filenames in Cygwin 1.7.x,
I'm contemplating not doing what I'd previously mentioned - using new
changes in GNU make to allow MS-DOS file names like "c:\foo" in
makefiles. I'll have to investigate just how much the Windows-isms in
GNU make's code impact Cygwin make before I make a final determination.
I may just decide to reenable the --ms-dos option as it used to be in
the old days. Or, if that's too much work, I might just turn off
special-case handling of c:\blah entirely - just like it is in
make-3.81.
FYI.
Thanks for the heads up.
On Cygwin, make-3.82 supports DOS paths by default. I'm curious about
what work might be involved in re-enabling the --ms-dos option, and I'd
like to help, if I can.
I built my Cygwin make-3.82 packages directly from the upstream release
tarball using the attached script.
-Rob
#!/bin/bash
# naming convention and rules for generation from http://cygwin.com/setup.html
PACKAGE=make
VERSION=3.82
# release number
RELEASE=1
PACKAGE_BIN_FILE=${PACKAGE}-${VERSION}-${RELEASE}.tar.bz2
PACKAGE_SRC_FILE=${PACKAGE}-${VERSION}-${RELEASE}-src.tar.bz2
# constructed stuff
PACKAGE_BIN_DIR=usr
PACKAGE_SRC_DIR=${PACKAGE}-${VERSION}-${RELEASE}
# stuff for building
VENDOR_DIR=make-3.82
VENDOR_FILE=${VENDOR_DIR}.tar.gz
BUILD_PREFIX=/usr
# whack anything generated
rm -f -r ${PACKAGE_BIN_FILE} \
${PACKAGE_BIN_DIR} \
${PACKAGE_SRC_FILE} \
${PACKAGE_SRC_DIR} \
${VENDOR_DIR} \
|| exit 1
if [ "$1" = "clean" ]
then
exit 0
fi
# unpack tarball
tar zxf ${VENDOR_FILE} || exit 1
# archive source for package
cp -r ${VENDOR_DIR} ${PACKAGE_SRC_DIR} || exit 1
# construct PACKAGE_SRC_FILE from archive
(tar cf - --owner=0 --group=0 ${PACKAGE_SRC_DIR} |
bzip2 > ${PACKAGE_SRC_FILE}) || exit 1
if [ "$1" = "nobuild" ]
then
exit 0
fi
pushd ${PACKAGE_SRC_DIR} || exit 1
# run ./configure
./configure --prefix=${BUILD_PREFIX} || exit 1
# note that make needs an absolute path for installation
make prefix="$(pwd)/../${PACKAGE_BIN_DIR}" install || exit 1
popd
(tar cf - --owner=0 --group=0 ${PACKAGE_BIN_DIR} | \
bzip2 > ${PACKAGE_BIN_FILE}) || exit 1
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Update on status of make-3.82 release for cygwin
On Tue, Aug 10, 2010 at 01:13:41PM -0700, Rob Walker wrote: >On Cygwin, make-3.82 supports DOS paths by default. I'm curious about >what work might be involved in re-enabling the --ms-dos option, and I'd >like to help, if I can. > >I built my Cygwin make-3.82 packages directly from the upstream release >tarball using the attached script. I don't need help. I've been building make for years so I obviously don't need your script. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Update on status of make-3.82 release for cygwin
Am 10.08.2010, 19:54 Uhr, schrieb Christopher Faylor: I wanted to let everyone know that I'm aware of the fact that make-3.82 has been released. However, given the number of reported problems in the make bugs mailing list, I don't plan on releasing a new version of GNU make until the dust has settled. That means no new version of make for at least a month. Also, given the ability to use more UNIX-like filenames in Cygwin 1.7.x, I'm contemplating not doing what I'd previously mentioned - using new changes in GNU make to allow MS-DOS file names like "c:\foo" in makefiles. I'll have to investigate just how much the Windows-isms in GNU make's code impact Cygwin make before I make a final determination. I may just decide to reenable the --ms-dos option as it used to be in the old days. Or, if that's too much work, I might just turn off special-case handling of c:\blah entirely - just like it is in make-3.81. How about pointing people to mingw-make? I've been using that to build ntemacs for quite a while... -- 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: [ANNOUNCEMENT] Update on status of make-3.82 release for cygwin
On Tue, Aug 10, 2010 at 10:51:38PM +0200, Matthias Andree wrote: >Am 10.08.2010, 19:54 Uhr, schrieb Christopher Faylor: > >> I wanted to let everyone know that I'm aware of the fact that make-3.82 >> has been released. However, given the number of reported problems in >> the make bugs mailing list, I don't plan on releasing a new version of >> GNU make until the dust has settled. That means no new version of make >> for at least a month. >> >> Also, given the ability to use more UNIX-like filenames in Cygwin 1.7.x, >> I'm contemplating not doing what I'd previously mentioned - using new >> changes in GNU make to allow MS-DOS file names like "c:\foo" in >> makefiles. I'll have to investigate just how much the Windows-isms in >> GNU make's code impact Cygwin make before I make a final determination. >> I may just decide to reenable the --ms-dos option as it used to be in >> the old days. Or, if that's too much work, I might just turn off >> special-case handling of c:\blah entirely - just like it is in >> make-3.81. > >How about pointing people to mingw-make? I've been using that to build >ntemacs for quite a while... http://cygwin.com/ml/cygwin-announce/2008-02/msg6.html -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Update on status of make-3.82 release for cygwin
On 8/10/2010 1:21 PM, Christopher Faylor wrote: On Tue, Aug 10, 2010 at 01:13:41PM -0700, Rob Walker wrote: On Cygwin, make-3.82 supports DOS paths by default. I'm curious about what work might be involved in re-enabling the --ms-dos option, and I'd like to help, if I can. I built my Cygwin make-3.82 packages directly from the upstream release tarball using the attached script. I don't need help. I've been building make for years so I obviously don't need your script. Sorry for the confusion: I was not offering my script as "hey look, here's how you do it", I was more saying "I did it this way, but maybe that's too simple. What else is involved, and can I help with that?" So: I'm still curious about the work you anticipate might be required. There's not much on the Cygwin site detailing the responsibilities of a package maintainer beyond: /Do you have the time to maintain the package?/ Packages without active maintainers are pulled from the distribution. Generally speaking the time commitment is relatively low, simply subscribe to the cygwin mailing list. We'd prefer if you read the non-digest mode since prompt response to packaging issues is a plus. When a /bug/ in your package is reported in the cygwin mailing list, address the bug (if it's a Cygwin-only bug) or pass back to the vendor. When a solution exists, create an updated package with the fix in it, and send a notification that you need the package uploaded to cygwin-apps. Note that you are not expected to be a helpdesk for the package - the users should be pointed to the vendors lists if you've determined that the bug is not a Cygwin-related bug. Thanks, Rob -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Update on status of make-3.82 release for cygwin
On 8/10/2010 5:04 PM, Rob Walker wrote: On 8/10/2010 1:21 PM, Christopher Faylor wrote: On Tue, Aug 10, 2010 at 01:13:41PM -0700, Rob Walker wrote: On Cygwin, make-3.82 supports DOS paths by default. I'm curious about what work might be involved in re-enabling the --ms-dos option, and I'd like to help, if I can. I built my Cygwin make-3.82 packages directly from the upstream release tarball using the attached script. I don't need help. I've been building make for years so I obviously don't need your script. Sorry for the confusion: I was not offering my script as "hey look, here's how you do it", I was more saying "I did it this way, but maybe that's too simple. What else is involved, and can I help with that?" So: I'm still curious about the work you anticipate might be required. There's not much on the Cygwin site detailing the responsibilities of a package maintainer beyond: It's a maintainer's responsibility to decide what's the best way to package the software for Cygwin. Obviously, there are basic guidelines, such as package naming, build scripts, and the like. But the rest is up to the maintainer. So if a maintainer doesn't think a feature fits well with Cygwin usage, then he/she is free to modify the package to disable that feature. Ditto if the feature is normally disabled but would be better enabled for Cygwin. This is the process that Chris is going through right now for make-3.82. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
On Aug 10 13:44 +0200 Corinna Vinschen wrote:
> > On Aug 10 00:19, John Carey wrote:
...
> > Presumably the issues mentioned in the source comment may
> > also occur, but what I have seen myself is a subsequent call to
> > SetCurrentDirectory() closing, not the current directory handle, but
> > the handle that was allocated by the other thread.
> >
> > Specifically, dll_crt0_1() calls sigproc_init(), then cwdstuff::set(),
> > and finally wait_for_sigthread(). The function sigproc_init() creates
> > the signal handling thread, which creates the signal handling pipe as
> > one of its very first actions, then sets the event for which
> > wait_for_sigthread() waits. I think this scenario happens:
> >
> > 1. main thread: cwdstuff::set(): NtClose().
> >
> > 2. signal handling thread: CreatePipe() opens a handle to
> > '\Device\NamedPipe\' and stores it in a global variable (because
> > this is the first call to CreatePipe()).
> >
> > 3. main thread: cwdstuff::set(): DuplicateHandle().
> >
> > In this case, the current directory handle value has changed, which is
> > not the intend of the NtClose-Duplicate sequence.
>
> No, that's not intended. However, the code just *tries* to preserve the
> handle value, but it does not rely on it. The NtClose is safe because
> the handle is the actual CWD handle at the time of the call and the PEB
> is locked. The DuplicateHandle call just uses the phdl storage to store
> the new handle value, but it *never* tests if the new handle value is
> identical to the old one. So, if all works well, it's the same handle
> value as before. If not, *shrug*.
>
> > CreateFile to fail with ERROR_INVALID_HANDLE as mentioned in the
> > source comments, but I have not seen that. I think that the
>
> I have. You can easily test this as well on Vista and W7. Just drop
> the DuplicateHandle call and simply store h in *phdl. Then create a
> testcase:
>
> chdir ("/");
> h = CreateFile ("foobar", ...);
> if (h == INVALID_HANDLE_VALUE) printf ("%lu\n", GetLastError());
Thanks for the test case for the CreateFile() problem; I used it to
create the following test, in which Windows 7 CreateFile() fails with
ERROR_INVALID_HANDLE even when using a stock Cygwin 1.7.5 DLL:
> bu...@aeolus-w764c17 ~
> $ uname -a
> CYGWIN_NT-6.1-WOW64 aeolus-w764c17 1.7.5(0.225/5/3) 2010-04-12 19:07 i686
> Cygwin
>
>
> bu...@aeolus-w764c17 ~
> $ cat test.c
> #include
> #include
> #include
> #include
> #include
>
> pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
>
> void * run (void *arg)
> {
> int count = (int)arg >> 1;
> int sync = (int)arg & 1;
>
> while (count--) {
> if (sync) pthread_mutex_lock(&mutex);
>
> HANDLE h = CreateFile (
> "foobar",
> GENERIC_WRITE,
> 0,
> NULL,
> CREATE_ALWAYS,
> FILE_ATTRIBUTE_NORMAL,
> INVALID_HANDLE_VALUE);
> if (h == INVALID_HANDLE_VALUE) {
> printf ("%lu\n", GetLastError());
> exit(1);
> }
> CloseHandle(h);
>
> if (sync) pthread_mutex_unlock(&mutex);
> }
>
> return 0;
> }
>
> int main (int argc, char** argv)
> {
> int count;
> int sync;
> pthread_t tid;
> void *result;
>
> if (argc != 2 && argc != 3) {
> fprintf(stderr, "Usage: %s []\n", argv[0]);
> return 2;
> }
>
> count = atol (argv[1]);
> sync = argc >= 3 ? !!atoi(argv[2]) : 0;
>
> pthread_create (&tid, 0, &run, (void*)((count << 1) | sync));
> while (count--) {
> if (sync) pthread_mutex_lock(&mutex);
> chdir ("/");
> if (sync) pthread_mutex_unlock(&mutex);
> }
>
> pthread_join (tid, &result);
> return 0;
> }
>
> bu...@aeolus-w764c17 ~
> $ gcc -o ~/test ~/test.c
>
> bu...@aeolus-w764c17 ~
> $ ~/test 1000 1
> 123
>
> bu...@aeolus-w764c17 ~
> $ ~/test 1000 0
> 123
>
> bu...@aeolus-w764c17 ~
> $ cd /
>
> bu...@aeolus-w764c17 /
> $ ~/test 1000 1
>
> bu...@aeolus-w764c17 /
> $ ~/test 1000 0
> 6
>
> bu...@aeolus-w764c17 /
> $
6 = "The handle is invalid.":
I think that this is the error previously discussed.
Note that passing "1" as the second program argument
synchronizes the two threads and prevents the error.
123 = "The filename, directory name, or volume label syntax is incorrect.":
I have not yet investigated why that error occurs, but it does
not happen if I run the test in the Cygwin root directory.
...
> > I think this other scenario also happens:
> >
> > 1. signal handling thread: CreatePipe() opens a handle to
> > '\Device\NamedPipe\' (because it is the first call to CreatePipe()).
> >
> > 2. main thread: cwdstuff::set(): NtClose().
> >
> > 3. signal handling thread: CreatePipe() opens pipe handles.
> >
> > 4. main thread: cwdstuff::set(): DuplicateHandle().
> >
> > In this case it is Cygwin signal handling that is sabotaged by
> > subsequent calls to SetCurrentDirectory(), because they
Missing APPDATA var in env of ssh sessions?
The mingw.org folks are developing a new installer, which uses WININET.dll facilities for d/l support. When I ran the application from within a cygwin shell, I ended up with the following debris in my testing /bin dir: $ pwd /c/msys-src/__xml/_test/bin $ ls libgcc_s_dw2-1.dll mingw-get.exe* $ ./mingw-get.exe update $ ls %APPDATA%/ libgcc_s_dw2-1.dll mingw-get.exe* $ find %APPDATA% %APPDATA% %APPDATA%/Microsoft %APPDATA%/Microsoft/Windows %APPDATA%/Microsoft/Windows/IETldCache %APPDATA%/Microsoft/Windows/IETldCache/index.dat Some googling indicates that this stuff is part of the network support provided by IE8 (or, the bits of Windows' networking that is provided by the DLLs associated with IE8). index.dat is a database for determining which domains are TLDs, and is user-customizable. If missing, it appears the IE8/WININET.dll/SHLWAPI.dll create it automatically. But the key is, it appears that the culprit, SHLWAPI.dll, checks the environment for %APPDATA% rather than using the MS-approved mechanism: SHGetSpecialFolderPath( 0, // Hwnd strPath, // String buffer. CSIDL_APPDATA, // CSLID of folder FALSE ); // Create if doesn't exists? $ strings /c/Windows/System32/SHLWAPI.dll | grep -i APPDATA %APPDATA% Now, a cmd box has this variable set: C:\Users\me>echo %APPDATA% C:\Users\me\AppData\Roaming If I start a bash shell within that cmd box: C:\Users\me>c:\cygwin-1.7\bin\bash --login the variable is still set: m...@computer[1.7] ~ $ echo $APPDATA C:\Users\me\AppData\Roaming The trick is, when I ssh in to the machine (even loopback), I don't have that env var: $ ssh localhost $ echo $APPDATA $ Now, this is a minor issue (does "mingw-get" work when invoked from a cygwin shell as part of a remote session?) However, I expect that the same flaw -- windows networking DLLs checking for %APPDATA% rather than using the Win32 API function -- would affect any native networking program that is launched from a cygwin remote session. Can ssh (or is it cygwin1.dll?) ensure that the user's APPDATA variable is populated, since it appears to be a pretty important var for Windows Vista+? -- 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
Cygwin DLL 1.7.5-1 would not interfere with Symantec anti virus?
Hello. One of the issues fixed under the New Cygwin DLL 1.7.5-1 release is the memory leak. Does this mean that we wont have any problems ruuning anti virus software like Symantec anymore? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Update on status of make-3.82 release for cygwin
On Tue, Aug 10, 2010 at 02:04:47PM -0700, Rob Walker wrote: >On 8/10/2010 1:21 PM, Christopher Faylor wrote: >> On Tue, Aug 10, 2010 at 01:13:41PM -0700, Rob Walker wrote: >> >>> On Cygwin, make-3.82 supports DOS paths by default. I'm curious about >>> what work might be involved in re-enabling the --ms-dos option, and I'd >>> like to help, if I can. >>> >>> I built my Cygwin make-3.82 packages directly from the upstream release >>> tarball using the attached script. >>> >> I don't need help. I've been building make for years so I obviously >> don't need your script. > >Sorry for the confusion: I was not offering my script as "hey look, >here's how you do it", I was more saying "I did it this way, but maybe >that's too simple. What else is involved, and can I help with that?" Once again: Don't need help. If you are thinking about maintaining a cygwin package then watch what is being discussed in cygwin-apps and read the "Cygwin Packages" link on the Cygwin web site. If you have a general question about cygwin packages then ask it. I'm not going to be providing you with my personal insights about make, however. 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: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
On Tue, Aug 10, 2010 at 09:53:46PM +, John Carey wrote: >Thanks for the test case for the CreateFile() problem; I used it to >create the following test, in which Windows 7 CreateFile() fails with >ERROR_INVALID_HANDLE even when using a stock Cygwin 1.7.5 DLL: As Corinna said: If you are mixing Windows calls with cygwin calls you are far into unsupported territory. Cygwin isn't designed to let you seamlessly intermix things like pthreads/signals and the Windows API functions. If you can demonstrate a problem with pure Cygwin calls then go ahead and post a test case. Otherwise, I don't see this as an issue that needs to be addressed. 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: [ANNOUNCEMENT] Update on status of make-3.82 release for cygwin
On 8/10/2010 10:38 PM, Christopher Faylor wrote: On Tue, Aug 10, 2010 at 02:04:47PM -0700, Rob Walker wrote: On 8/10/2010 1:21 PM, Christopher Faylor wrote: On Tue, Aug 10, 2010 at 01:13:41PM -0700, Rob Walker wrote: On Cygwin, make-3.82 supports DOS paths by default. I'm curious about what work might be involved in re-enabling the --ms-dos option, and I'd like to help, if I can. I built my Cygwin make-3.82 packages directly from the upstream release tarball using the attached script. I don't need help. I've been building make for years so I obviously don't need your script. Sorry for the confusion: I was not offering my script as "hey look, here's how you do it", I was more saying "I did it this way, but maybe that's too simple. What else is involved, and can I help with that?" Once again: Don't need help. If you are thinking about maintaining a cygwin package then watch what is being discussed in cygwin-apps I am thinking about maintaining a Cygwin package. I have re-subscribed to cygwin-apps to try to get de-noobed. and read the "Cygwin Packages" link on the Cygwin web site. I've read that page pretty closely. The result was my construction and offer of make-3.81-4 Cygwin packages to address the lack of support for colons in paths, and later, make-3.82 Cygwin packages. If you have a general question about cygwin packages then ask it. My general question was: "What requirements does a package maintainer need to consider, what tests must pass, etc. when constructing a Cygwin package from an upstream release?" The answer (which I am paraphrasing from Larry Hall's response on the matter) seems to be basically: "Whatever the package maintainer thinks is right." -Rob -- 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
