Re: Basic question about cygport
On Aug 5 00:17, Steven Penny wrote: On Mon, Aug 4, 2014 at 11:28 PM, Andrey Repin wrote: Nobody care. Really. Noone going to recheck your answers to see is they are relevant to the current Cygwin realities. Which is a part of issue. Cygwin is evolving, and answers found all around the internet, copypasted for years without even little thinking, are going to be useless (at best!) at one point in future. At worst, they would be disastrous. The only place where you can get actual (as in relevant to the current state of the project) support is this mailing list. Or cygwin-xfree, if your question is X-relevant. Hey buddy, why dont you crawl back into your hole. You long winded and baseless insults toward Stack Overflow and myself show just how out of touch you are. Why dont do everyone a favor and post something on topic, like an answer to the OP, or hush? Steven. Stop right here. This list has a WJM history, granted, but there are borders of shitty attitude which I won't tolerate. I'm not going to involve myself into an endless flamewar thread so don't expect any useless arguing with you. Rather, make sure that you're staying more polite or there will be consequences. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpPHn4VibLMd.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Updated [experimental]: coreutils-8.23-1
On Aug 3 11:28, Steven Penny wrote: On Sat, Aug 2, 2014 at 2:29 PM, Eric Blake (cygwin) wrote: Yes, I'm aware that it has been more than 2 years since I last built coreutils, and that there has been some question on the mailing list of whether I'm being responsive enough as a maintainer. I apologize for the delays in getting this release made, but I'd still like to hang on to this package a bit longer, particularly since I'm most familiar with the set of cygwin-only downstream patches needed to make the package play nicely with the Cygwin environment. Let me be the first to say thank you for the update. I know that Cygwin packages are not always easy to make because they sometimes do not compile out of the box and require manual patching. As far as you staying on, I am personally fine with it as long as you can update at least once per year. That seems like a reasonable timeframe. You're invited to become Cygwin package maintainer yourself, then you have the perfect right to update your own packages in what you perceive as a reasonable timeframe. And you can collaborate with other maintainers on combined updates of dependent packages. As user, you may ask for an update, but it's up to the maintainers to decide what a reasonable timeframe is. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpB9_TF7bxGF.pgp Description: PGP signature
Re: Basic question about cygport
Philip Daniels philip.daniels1971 at gmail.com writes:
A while ago I asked a question on Stack Overflow about doing a basic
install task with cygport, but got no answers. Too esoteric perhaps. I
think it should be easy for anyone who knows cygport, it's a basic copy
some files to a known location task.
It wouldn't hurt to just ask the question again here instead of sending
people off to read it elsewhere. If you want to track the problem down
yourself, read /usr/share/doc/cygport/manual.html -- then running cygport
with the --debug switch gives you plenty of output to tell you what's going
on when you run the failing commands. That said, you might look at a
cygport file that uses insinto/doins and adapt it (from gnuplot):
mkdir -p ${D}/etc/X11/app-defaults
insinto /etc/X11/app-defaults/Gnuplot
doins ${D}/usr/share/gnuplot/${myPV_MAJ_MIN}/app-defaults/Gnuplot
Hope this helps.
Regards,
Achim.
--
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: passwd (cygwin) 1.7.31 ignores keyboard interrupts
On Aug 4 13:40, Doug Henderson wrote: The password utility /bin/passwd ignores the ^C and ^D interrupt characters in mintty in my 64-bit only cygwin environment. That's kind of by design. The passwd tool uses the getpass function. The getpass function is written so that it ignores any soft tty signal (^C, ^D, ^Z) during password input for security reasons. This is in line with the Linux/Glibc implementation. This can lead to inadvertent password changes, possibly requiring a lengthy or complex password recovery or reset. I see. The problem here is that passwd is using the getpass function. It should (probably) either use another input function or it should explicitely test for ^C, ^D, and ^Z characters in the input string to workaround the getpass security restriction. The latter would allow to disregard the input string and exiting passwd after the user pressed Enter. I'll look into it at one point, but I also wouldn't be too unhappy about a patch. Please see https://cygwin.com/contrib.html Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpniFFkKGpxT.pgp Description: PGP signature
Re: cannot display man page for /bin/passwd
On Aug 4 13:48, Doug Henderson wrote: When I try to display the man page for /bin/passwd, the man page for the openssl passwd subcommand is displayed. It appears that both the package containing /bin/passwd, and the openssl package place the passwd.1.gz file in the /usr/share/man/man1 directory, so that only the man page from the most recently installed package is displayed. No, the Cygwin passwd tool has no man page. The documentation is only in the User's Guide: https://cygwin.com/cygwin-ug-net/using-utils.html#passwd Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp88OgSoQAu2.pgp Description: PGP signature
Re: Basic question about cygport
Greetings, Steven Penny! You long winded and baseless insults toward Stack Overflow and myself show just how out of touch you are. I didn't said anything about StackOverflow and/or yourself. If you open your eyes and read the text you quoted, you'll see it. And I'm not waving my own stackexchange account like a flag of some sort. Why dont do everyone a favor and post something on topic, like an answer to the OP, or hush? When one of twenty people, who can answer your question, see your message and find time to reply to it, you'll get your answer, if you didn't already. Meanwhle, please take a note, that when you post a question in mailing list, you should provide details in the same message, if at all possible. For continuity of the discussion, and for people, who would be searching the same question later in the archives. If that's not too much of work for you. -- WBR, Andrey Repin (anrdae...@yandex.ru) 05.08.2014, 12:21 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: (call-process ...) hangs in emacs
On 8/4/2014 9:45 AM, Corinna Vinschen wrote: On Aug 4 09:34, Ken Brown wrote: On 8/4/2014 4:00 AM, Corinna Vinschen wrote: On Aug 3 21:02, Ken Brown wrote: On 8/1/2014 9:32 AM, Corinna Vinschen wrote: It could be a problem with the new default pthread mutexes being NORMAL, rather then ERRORCHECK mutexes. That does seem to be the problem, since I can reproduce the bug starting with the 2014-07-14 snapshot. More precisely, I can reproduce it using emacs-nox (which is what the OP was using according to his cygcheck output) but not using emacs-X11 or emacs-w32. I tried running emacs under gdb with a breakpoint at call_process, but all I could see from that is that emacs tries to fork a subprocess, but the call to fork() never returns. I also tried running it under strace, but again all I can see is that fork() is called and then everything seems to be at a standstill. Corinna, if you want to take a look, here's the precise recipe: 1. emacs-nox -Q [This should start emacs and put you in the *scratch* buffer.] 2. Enter the following text into the buffer: (call-process pwd nil t) 3. Position the cursor at the end of the line and type Ctrl-j. What should happen, and what does happen prior to the 2014-07-14 snapshot, is that the current directory is displayed, followed by the exit code of 0. What happens instead is that emacs appears to hang. How does emacs start a process? Does it create a thread and then forks and execs from the thread? Does it use its own pthread_mutex to control the job? Is there a chance to create an STC of this process? emacs does some bookkeeping and then calls vfork. It does not create a new thread, nor does it create a pthread_mutex. The only pthread_mutexes created anywhere in the emacs source code are in its implementation of malloc and friends, not in anything directly related to controlling subprocesses. (FWIW, this malloc implementation is used in the Cygwin build of emacs but not in the Linux build.) Can you take a close look here? This malloc will be used by Cygwin as well if it's implemented in the usual way and... I did think about trying to create an STC, but I'm stymied because the problem depends so strongly on how emacs is run: - If emacs is run interactively, the problem only occurs with emacs-nox, not with emacs-X11 or emacs-w32. - If emacs is run non-interactively (i.e., in batch mode), the problem occurs with emacs-w32 and emacs-X11 too, as Angelo and Katsumi pointed out earlier in the thread. I can't think of any way to capture these peculiarities in an STC. ...this, and the fact that fork/exec (vfork == fork on Cygwin) still works nicely in other scenarios points to some problem with the usage of pthread_mutexes in the application may be the culprit. For instance, is it possible that emacs expects the pthread_mutexes in malloc to be ERRORCHECK mutexes? What if you explicitely set them to ERRORCHECK at creation time? That doesn't seem to be the issue, but I think I did find the problem, and it looks like there might be both an emacs bug and a Cygwin bug. Here's the relevant code from emacs's gmalloc.c: pthread_mutex_t _malloc_mutex = PTHREAD_MUTEX_INITIALIZER; pthread_mutex_t _aligned_blocks_mutex = PTHREAD_MUTEX_INITIALIZER; [...] /* Some pthread implementations call malloc for statically initialized mutexes when they are used first. To avoid such a situation, we initialize mutexes here while their use is disabled in malloc etc. */ pthread_mutex_init (_malloc_mutex, NULL); pthread_mutex_init (_aligned_blocks_mutex, NULL); The pthread_mutexes are initialized twice, resulting in undefined behavior according to Posix. That's the emacs bug. But simply removing the static initialization doesn't fix the problem. On the other hand, the following patch does seem to fix it, at least in preliminary testing: === modified file 'src/gmalloc.c' --- src/gmalloc.c 2014-03-04 19:02:49 + +++ src/gmalloc.c 2014-08-05 01:35:38 + @@ -490,8 +490,8 @@ } #ifdef USE_PTHREAD -pthread_mutex_t _malloc_mutex = PTHREAD_MUTEX_INITIALIZER; -pthread_mutex_t _aligned_blocks_mutex = PTHREAD_MUTEX_INITIALIZER; +pthread_mutex_t _malloc_mutex; +pthread_mutex_t _aligned_blocks_mutex; int _malloc_thread_enabled_p; static void @@ -526,8 +526,11 @@ initialized mutexes when they are used first. To avoid such a situation, we initialize mutexes here while their use is disabled in malloc etc. */ - pthread_mutex_init (_malloc_mutex, NULL); - pthread_mutex_init (_aligned_blocks_mutex, NULL); + pthread_mutexattr_t attr1, attr2; + pthread_mutexattr_settype (attr1, PTHREAD_MUTEX_NORMAL); + pthread_mutexattr_settype (attr2, PTHREAD_MUTEX_NORMAL); + pthread_mutex_init (_malloc_mutex, attr1); + pthread_mutex_init (_aligned_blocks_mutex, attr2); pthread_atfork (malloc_atfork_handler_prepare, malloc_atfork_handler_parent,
Re: Missing 64 bit packages
Dan Kegel dank at kegel.com writes: perl-libwin32 I probably don't need it myself, but was curious whether there were any problems with the port (other than lack of time). The libwin32 doesn't exist anymore (it's become a bundle), of the individual modules that comprise it, I can only speak for Win32-API and Win32-OLE in their latest incarnations. They both build, but have a few test problems. Win32-API apparently has the same problems for both 32bit and 64bit, so it may be a test issue. For Win32-OLE, again both architectures, the Excel test fails, which looks like a problem of the version of Excel I'm using (Excel complains it doesn't have enough memory, those failures started after an update of Excel). Regards, Achim. -- 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
About freeglut
Just for completeness... I discovered that my Cygwin installation (Cygwin64) tree has these files /usr/src/freeglut-2.8.1.tar.gz /usr/src/freeglut.cygport which belong to freeglut-src package (as reported by http://cygwin.com/packages). Usually I install ONLY binary packages but could be I did the wrong choice so I tried to install the binaries of that package but... setup.exe offers only freeglut-debuginfo and the mirorrs (at least mirrors.kernel.org and sourceware.mirrors.tds.net) do not even have the freeglut directory under x86_64/release.. It looks to me there is something wrong.. Ciao, Angelo. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated [experimental]: coreutils-8.23-1
Eric Blake (cygwin) wrote: A new release of coreutils, 8.23-1, is available for download for testing purposes, leaving 8.15-1 (32-bit) or 8.15-3 (64-bit) as current for another week until I am sure there are no major regressions. Been trying this. No problems so far. -- 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: (call-process ...) hangs in emacs
On Tue, Aug 5, 2014 at 1:21 PM, Ken Brown kbr...@cornell.edu wrote: - pthread_mutex_init (_malloc_mutex, NULL); - pthread_mutex_init (_aligned_blocks_mutex, NULL); + pthread_mutexattr_t attr1, attr2; + pthread_mutexattr_settype (attr1, PTHREAD_MUTEX_NORMAL); + pthread_mutexattr_settype (attr2, PTHREAD_MUTEX_NORMAL); + pthread_mutex_init (_malloc_mutex, attr1); + pthread_mutex_init (_aligned_blocks_mutex, attr2); pthread_atfork (malloc_atfork_handler_prepare, malloc_atfork_handler_parent, malloc_atfork_handler_child); Does there need to be a 'pthread_mutexattr_init' in there? I don't think that's the problem though... Pete -- 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: cannot display man page for /bin/passwd
From: Corinna Vinschen No, the Cygwin passwd tool has no man page. The documentation is only in the User's Guide: https://cygwin.com/cygwin-ug-net/using-utils.html#passwd But then, how to explain the following? $ man passwd | head PASSWD(1) CYGWIN PASSWD(1) NAME - Change USER's password or password attributes. SYNOPSIS passwd [OPTION] [USER] $ --Ken Nellis
Re: (call-process ...) hangs in emacs
On Aug 5 08:21, Ken Brown wrote: On 8/4/2014 9:45 AM, Corinna Vinschen wrote: ...this, and the fact that fork/exec (vfork == fork on Cygwin) still works nicely in other scenarios points to some problem with the usage of pthread_mutexes in the application may be the culprit. For instance, is it possible that emacs expects the pthread_mutexes in malloc to be ERRORCHECK mutexes? What if you explicitely set them to ERRORCHECK at creation time? That doesn't seem to be the issue, but I think I did find the problem, and it looks like there might be both an emacs bug and a Cygwin bug. Here's the relevant code from emacs's gmalloc.c: pthread_mutex_t _malloc_mutex = PTHREAD_MUTEX_INITIALIZER; pthread_mutex_t _aligned_blocks_mutex = PTHREAD_MUTEX_INITIALIZER; [...] /* Some pthread implementations call malloc for statically initialized mutexes when they are used first. To avoid such a situation, we initialize mutexes here while their use is disabled in malloc etc. */ pthread_mutex_init (_malloc_mutex, NULL); pthread_mutex_init (_aligned_blocks_mutex, NULL); The pthread_mutexes are initialized twice, resulting in undefined behavior according to Posix. That's the emacs bug. That's not the problem. It's not necessary to call pthread_mutex_init on statically initialized mutexes, but it doesn't hurt either. Only when calling pthread_mutex_init twice on the same object it goes downhill, especially when the first incarnation of the mutex was already locked. But simply removing the static initialization doesn't fix the problem. On the other hand, the following patch does seem to fix it, at least in preliminary testing: === modified file 'src/gmalloc.c' --- src/gmalloc.c 2014-03-04 19:02:49 + +++ src/gmalloc.c 2014-08-05 01:35:38 + @@ -490,8 +490,8 @@ } #ifdef USE_PTHREAD -pthread_mutex_t _malloc_mutex = PTHREAD_MUTEX_INITIALIZER; -pthread_mutex_t _aligned_blocks_mutex = PTHREAD_MUTEX_INITIALIZER; +pthread_mutex_t _malloc_mutex; +pthread_mutex_t _aligned_blocks_mutex; int _malloc_thread_enabled_p; static void @@ -526,8 +526,11 @@ initialized mutexes when they are used first. To avoid such a situation, we initialize mutexes here while their use is disabled in malloc etc. */ - pthread_mutex_init (_malloc_mutex, NULL); - pthread_mutex_init (_aligned_blocks_mutex, NULL); + pthread_mutexattr_t attr1, attr2; + pthread_mutexattr_settype (attr1, PTHREAD_MUTEX_NORMAL); + pthread_mutexattr_settype (attr2, PTHREAD_MUTEX_NORMAL); + pthread_mutex_init (_malloc_mutex, attr1); + pthread_mutex_init (_aligned_blocks_mutex, attr2); pthread_atfork (malloc_atfork_handler_prepare, malloc_atfork_handler_parent, malloc_atfork_handler_child); The first hunk avoids the double initialization, but I don't understand why the second hunk does anything. Since PTHREAD_MUTEX_NORMAL is now the default, shouldn't calling pthread_mutex_init with NULL second argument be equivalent to my calls to pthread_mutexattr_settype? Does this indicate a Cygwin bug, or am I misunderstanding something? AFAICS you're missing something. Your pthread_mutexattr_t attr1, attr2 are not initialized. They contain some random values, thus they are not good objects. The calls to pthread_mutexattr_settype as well as the calls to pthread_mutex_init will fail with EINVAL, but you won't see it due to missing error handling, and you end up without mutexes at all. If you call pthread_mutexattr_init before calling pthread_mutexattr_settype the situation shoul;d be the same as before. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgprPE0TImYR3.pgp Description: PGP signature
Re: (call-process ...) hangs in emacs
In my experiments, not calling pthread_mutexattr_init caused errors such that the final mutex was invalid and could not be locked. The difference between the explicitly initialised mutex and the statically initialised one is that the latter does get 'lazily' initialised when the mutex is first locked (I think...?) so maybe the problem is something to do with the timing of that? Pete -- 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: About freeglut
On 05/08/2014 14:15, Angelo Graziosi wrote: Just for completeness... I discovered that my Cygwin installation (Cygwin64) tree has these files /usr/src/freeglut-2.8.1.tar.gz /usr/src/freeglut.cygport which belong to freeglut-src package (as reported by http://cygwin.com/packages). Usually I install ONLY binary packages but could be I did the wrong choice so I tried to install the binaries of that package but... setup.exe offers only freeglut-debuginfo and the mirrors (at least mirrors.kernel.org and sourceware.mirrors.tds.net) do not even have the freeglut directory under x86_64/release.. It looks to me there is something wrong.. I think the corresponding binary packages are libglut3 and libglut-devel. The packages are under release/X11/freeglut (for historical reasons) (freeglut is an opensource replacement for SGI glut) -- 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: cannot display man page for /bin/passwd
On Aug 5 13:43, Nellis, Kenneth wrote: From: Corinna Vinschen No, the Cygwin passwd tool has no man page. The documentation is only in the User's Guide: https://cygwin.com/cygwin-ug-net/using-utils.html#passwd But then, how to explain the following? $ man passwd | head PASSWD(1) CYGWIN PASSWD(1) NAME - Change USER's password or password attributes. SYNOPSIS passwd [OPTION] [USER] $ I don't have that, but a package search educated me that a passwd.1 man page is part of the cygwin-doc package. In the next OpenSSL release I will apply the same patch as the Linux maintainer, which is, rename the passwd.1 to sslpasswd.1. That should help. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpbF63bXL5V_.pgp Description: PGP signature
Re: cannot display man page for /bin/passwd
On Tue, Aug 5, 2014 at 2:21 AM, Corinna Vinschen wrote:
On Aug 4 13:48, Doug Henderson wrote:
When I try to display the man page for /bin/passwd, the man page for
the openssl passwd subcommand is displayed.
It appears that both the package containing /bin/passwd, and the
openssl package place the passwd.1.gz file in the /usr/share/man/man1
directory, so that only the man page from the most recently installed
package is displayed.
No, the Cygwin passwd tool has no man page. The documentation is
only in the User's Guide:
https://cygwin.com/cygwin-ug-net/using-utils.html#passwd
Corinna
My apologies if this is a transitional problem related to the recent
changes to the /etc/passwd file, but …
Attached is a short script to demonstrate the problem I described.
cyg-passwd.sh (attached with a .txt exension), will pause 3 times
while you run setup-x86_64.exe to 1) install pending changes and make
sure cygwin-doc and openssl are installed, 2) reinstall cygwin-doc, 3)
reinstall openssl.
Attached is the output from my short script.
Attached is the output from cygcheck -svr.
With 30+ years experience on *nix systems, the man page is my first
stop for usage details on any program.
I believe this problem should be directed to the attention of the
openssl package maintainer.
Thanks for your continued attention.
Doug
--
Doug Henderson, Calgary, Alberta, Canada
:
export MANWIDTH=80
rm -f cyg-passwd.txt
echo cyg-passwd.txt
echo -e \nrun setup to install all pending changes cyg-passwd.txt
echo -n run setup to install all pending changes :
read JUNK
echo -e \n$ cygcheck -l cygwin-doc cyg-passwd.txt
cygcheck -l cygwin-doc | grep passwd cyg-passwd.txt
echo -e \n$ cygcheck -l openssl cyg-passwd.txt
cygcheck -l openssl | grep passwd cyg-passwd.txt
echo -e \n$ cygcheck -cv cygwin-do cyg-passwd.txt
cygcheck -cv cygwin-doc cyg-passwd.txt
echo -e \n$ cygcheck -cv openssl cyg-passwd.txt
cygcheck -cv openssl cyg-passwd.txt
echo -e \nrun setup to reinstall cygwin-doc package cyg-passwd.txt
echo -n run setup to reinstall cygwin-doc package :
read JUNK
echo -e \n$ man passwd cyg-passwd.txt
man passwd | head cyg-passwd.txt
echo -e \nrun setup to reinstall openssl package cyg-passwd.txt
echo -n run setup to reinstall openssl package :
read JUNK
echo -e \n$ man passwd cyg-passwd.txt
man passwd | head cyg-passwd.txt
run setup to install all pending changes
$ cygcheck -l cygwin-doc
/usr/share/man/man1/mkpasswd.1.gz
/usr/share/man/man1/passwd.1.gz
$ cygcheck -l openssl
/usr/share/man/man1/passwd.1.gz
$ cygcheck -cv cygwin-do
Cygwin Package Information
Last downloaded files to: D:\Users\Doug\Downloads\cygwin
Last downloaded files from: http://mirrors.kernel.org/sourceware/cygwin/
Package VersionStatus
cygwin-doc 1.7-1 OK
$ cygcheck -cv openssl
Cygwin Package Information
Last downloaded files to: D:\Users\Doug\Downloads\cygwin
Last downloaded files from: http://mirrors.kernel.org/sourceware/cygwin/
Package VersionStatus
openssl 1.0.1h-1 OK
run setup to reinstall cygwin-doc package
$ man passwd
PASSWD(1) CYGWIN PASSWD(1)
NAME
- Change USER's password or password attributes.
SYNOPSIS
passwd [OPTION] [USER]
run setup to reinstall openssl package
$ man passwd
PASSWD(1) OpenSSL PASSWD(1)
NAME
passwd - compute password hashes
SYNOPSIS
openssl passwd [-crypt] [-1] [-apr1] [-salt string] [-in file] [-stdin]
[-noverify] [-quiet] [-table] {password}
Cygwin Configuration Diagnostics
Current System Time: Tue Aug 05 15:06:07 2014
Windows 7 Home Premium Ver 6.1 Build 7601 Service Pack 1
Path: D:\cygwin64\home\Doug\bin
D:\cygwin64\usr\local\bin
D:\cygwin64\bin
D:\oraclexe11g2\app\oracle\product\11.2.0\server\bin
C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common
C:\Program Files\Common Files\Microsoft Shared\Windows Live
C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live
C:\Windows\system32
C:\Windows
C:\Windows\System32\Wbem
C:\Windows\System32\WindowsPowerShell\v1.0
C:\Program Files (x86)\Windows Live\Shared
C:\Program Files (x86)\IronRuby 1.1\bin
D:\Go\Go64\bin
C:\Users\Doug\bin
D:\oraclexe11g2\app\oracle\product\11.2.0\server\bin
C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common
C:\Program Files\Common Files\Microsoft Shared\Windows Live
C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live
C:\Windows\system32
C:\Windows
C:\Windows\System32\Wbem
C:\Windows\System32\WindowsPowerShell\v1.0
C:\Program Files (x86)\Windows Live\Shared
C:\Program Files (x86)\IronRuby 1.1\bin
D:\Go\Go64\bin
Output from D:\cygwin64\bin\id.exe
UID: 1001(Doug) GID:
syslog function: Bad file descriptor
Hi group, I'm still working on getting Sendmail working for Cygwin. I'm almost done, the devil is in the details... I'm getting the 'Bad file descriptor' system error after building the mail aliases database. The building itself is done successful, but logging the event to the system log fails with this message. Somehow the two are connected. The alias database (aliases.db) is built from a plain text file (aliases). If I leave the aliases file writable to the sendmail user, I find that the error message strings have been put right into the alias text-file: $ cat /etc/mail/aliases 21sendmail: PID 1848: alias database /etc/mail/aliases rebuilt by smmspsenet: root news: root webmaster: root www: root ftp: root abuse: root noc: root security: root root: SYSTEM 22sendmail: PID 1848: /etc/mail/aliases: 9 aliases, longest 6 bytes, 82 bytes total If I make the 'aliases' file read-only, then the file is not corrupted, but the error occurs. Cheers, Daniel Here's the strace output. I copied the lines between two subsequent calls to 'syslog': strace /usr/sbin/sendmail -bi syslog: Bad file descriptor 145 16951672 [main] sendmail 1104 write: 28 = write(1, 0x2007EFB0, 28) 131 16951803 [main] sendmail 1104 cygpsid::debug_print: get_sids_info: owner SID = S-1-5-21-1659004503-813497703-854245398-1028 56 16951859 [main] sendmail 1104 cygpsid::debug_print: get_sids_info: group SID = S-1-5-21-1659004503-813497703-854245398-1029 55 16951914 [main] sendmail 1104 get_info_from_sd: ACL 0x120, uid 1028, gid 1029 74 16951988 [main] sendmail 1104 fhandler_base::fstat_helper: 0 = fstat (\??\C:\cygwin\etc\mail\aliases, 0x228A10) st_size=183, st_mode=0x8120, st_ino=1970324837070571st_atim=53E0FB5C.120ACC80 st_ctim=53E0FB59.1859C3C0 st_mtim=53E0FB4E.205C2E00 st_birthtim=53DE6678.2B7D5340 68 16952056 [main] sendmail 1104 fstat64: 0 = fstat(3, 0x228A10) 76 16952132 [main] sendmail 1104 read: read(3, 0x2008EFB8, 65536) blocking 73 16952205 [main] sendmail 1104 fhandler_base::read: returning 183, binary mode 50 16952255 [main] sendmail 1104 read: 183 = read(3, 0x2008EFB8, 65536) 333 16952588 [main] sendmail 1104 fhandler_disk_file::pread: 16384 = pread(0x2004D9D4, 16384, 32768) 63 16952651 [main] sendmail 1104 pread: 16384 = pread(6, 0x2004D9D4, 16384, 32768) 345 16952996 [main] sendmail 1104 fhandler_disk_file::pread: 16384 = pread(0x2009EFFC, 16384, 16384) 58 16953054 [main] sendmail 1104 pread: 16384 = pread(6, 0x2009EFFC, 16384, 16384) 2580 16955634 [main] sendmail 1104 read: read(3, 0x2008EFB8, 65536) blocking 69 16955703 [main] sendmail 1104 fhandler_base::read: returning 0, binary mode 48 16955751 [main] sendmail 1104 read: 0 = read(3, 0x2008EFB8, 65536) /etc/mail/aliases: 13 aliases, longest 10 bytes, 144 bytes total 196 16955947 [main] sendmail 1104 write: 65 = write(1, 0x2007EFB0, 65) 53 16956000 [main] sendmail 1104 vsyslog: 0x6 %s 243 16956243 [main] sendmail 1104 open: open(/dev/null, 0x10601) 51 16956294 [main] sendmail 1104 normalize_posix_path: src /dev/null 71 16956365 [main] sendmail 1104 normalize_posix_path: /dev/null = normalize_posix_path (/dev/null) 50 16956415 [main] sendmail 1104 mount_info::conv_to_win32_path: conv_to_win32_path (/dev/null) 48 16956463 [main] sendmail 1104 mount_info::conv_to_win32_path: src_path /dev/null, dst \Device\Null, flags 0x2, rc 0 64 16956527 [main] sendmail 1104 build_fh_pc: fh 0x612AEC2C, dev 00010003 51 16956578 [main] sendmail 1104 fhandler_base::open: (\Device\Null, 0x18601) 61 16956639 [main] sendmail 1104 fhandler_base::set_flags: flags 0x18601, supplied_bin 0x1 51 16956690 [main] sendmail 1104 fhandler_base::set_flags: O_TEXT/O_BINARY set in flags 0x1 50 16956740 [main] sendmail 1104 fhandler_base::set_flags: filemode set to binary 48 16956788 [main] sendmail 1104 fhandler_base::open: 0x0 = NtCreateFile (0x60C, 0x40120080, \Device\Null, io, NULL, 0x0, 0x7, 0x3, 0x4020, NULL, 0) 52 16956840 [main] sendmail 1104 fhandler_base::open: 1 = fhandler_base::open(\Device\Null, 0x18601) 51 16956891 [main] sendmail 1104 open: 7 = open(/dev/null, 0x18601) 190 16957081 [main] sendmail 1104 _cygwin_istext_for_stdio: fd 7: opened as binary 1045 16958126 [main] sendmail 1104 write: write(7, 0x227B50, 10) 49 16958175 [main] sendmail 1104 write: 10 = write(7, 0x227B50, 10) 169 16958344 [main] sendmail 1104 getpid: 1104 = getpid() 555 16958899 [main] sendmail 1104 write: write(7, 0x227B50, 10) 47 16958946 [main] sendmail 1104 write: 10 = write(7, 0x227B50, 10) 688 16959634 [main] sendmail 1104 write: write(7, 0x227B70, 64) 49 16959683 [main] sendmail 1104 write: 64 = write(7, 0x227B70, 64) 256 16959939 [main] sendmail 1104 close: close(7) 440 16960379 [main] sendmail 1104 fhandler_base::close: closing '/dev/null' handle 0x60C 36 16960415 [main] sendmail 1104 close: 0 = close(7) 616 16961031 [main] sendmail 1104 getpid: 1104 = getpid() 51 16961082 [main]
[ANNOUNCEMENT] Updated: openssl-1.0.1h-2
The following packages have been updated in the Cygwin distribution: * openssl-1.0.1h-2 * libopenssl100-1.0.1h-2 * openssl-devel-1.0.1h-2 This release fixes the passwd man page collision introduced with openssl-1.0.1h. If you have the cygwin-doc package installed as well, just update openssl as well as reinstall the cygwin-doc package, then you'll have the original passwd man page back. Have fun, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer 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: syslog function: Bad file descriptor
On 08/05/2014 12:28 PM, D. Boland wrote: Hi group, I'm still working on getting Sendmail working for Cygwin. I'm almost done, the devil is in the details... I'm getting the 'Bad file descriptor' system error after building the mail aliases database. The building itself is done successful, but logging the event to the system log fails with this message. Did you mention whether you've installed and configured some syslog service? -- Larry _ 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: syslog function: Bad file descriptor
Hi Daniel, On Aug 5 18:28, D. Boland wrote: Hi group, I'm still working on getting Sendmail working for Cygwin. I'm almost done, the devil is in the details... I'm getting the 'Bad file descriptor' system error after building the mail aliases database. The building itself is done successful, but logging the event to the system log fails with this message. Somehow the two are connected. The alias database (aliases.db) is built from a plain text file (aliases). If I leave the aliases file writable to the sendmail user, I find that the error message strings have been put right into the alias text-file: $ cat /etc/mail/aliases 21sendmail: PID 1848: alias database /etc/mail/aliases rebuilt by smmspsenet: root news: root webmaster: root www: root ftp: root abuse: root noc: root security: root root: SYSTEM 22sendmail: PID 1848: /etc/mail/aliases: 9 aliases, longest 6 bytes, 82 bytes total If I make the 'aliases' file read-only, then the file is not corrupted, but the error occurs. I don't see that this has to do with syslog. There's a writev to fd 3, but you stripped the strace so we don't know what fd 3 is connected to. Also, syslog writes the output to the Windows event log by default, unless you have a syslog daemon running, connected to /dev/log. So I guess we first have to know what fd 3 is connected to, and then how to reproduce the issue. Corinna pgpjT1_gv4nU8.pgp Description: PGP signature
Re: cannot display man page for /bin/passwd
On 08/05/2014 11:09 AM, Doug Henderson wrote: On Tue, Aug 5, 2014 at 2:21 AM, Corinna Vinschen wrote: On Aug 4 13:48, Doug Henderson wrote: When I try to display the man page for /bin/passwd, the man page for the openssl passwd subcommand is displayed. It appears that both the package containing /bin/passwd, and the openssl package place the passwd.1.gz file in the /usr/share/man/man1 directory, so that only the man page from the most recently installed package is displayed. No, the Cygwin passwd tool has no man page. The documentation is only in the User's Guide: https://cygwin.com/cygwin-ug-net/using-utils.html#passwd Corinna My apologies if this is a transitional problem related to the recent changes to the /etc/passwd file, but … Attached is a short script to demonstrate the problem I described. cyg-passwd.sh (attached with a .txt exension), will pause 3 times while you run setup-x86_64.exe to 1) install pending changes and make sure cygwin-doc and openssl are installed, 2) reinstall cygwin-doc, 3) reinstall openssl. Attached is the output from my short script. Attached is the output from cygcheck -svr. With 30+ years experience on *nix systems, the man page is my first stop for usage details on any program. I believe this problem should be directed to the attention of the openssl package maintainer. Thanks for your continued attention. Did you not see this https://cygwin.com/ml/cygwin/2014-08/msg00097.html and now this? https://cygwin.com/ml/cygwin/2014-08/msg00100.html -- Larry _ 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: syslog function: Bad file descriptor
On Aug 5 12:45, Larry Hall (Cygwin) wrote: On 08/05/2014 12:28 PM, D. Boland wrote: Hi group, I'm still working on getting Sendmail working for Cygwin. I'm almost done, the devil is in the details... I'm getting the 'Bad file descriptor' system error after building the mail aliases database. The building itself is done successful, but logging the event to the system log fails with this message. Did you mention whether you've installed and configured some syslog service? Indeed, that's not visible from the strace, The syslog function won't create any further debug output unless it fails to register with the Windows Event Log. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpADJz0Y0MT1.pgp Description: PGP signature
Re: syslog function: Bad file descriptor
Larry Hall (Cygwin) wrote: On 08/05/2014 12:28 PM, D. Boland wrote: Hi group, I'm still working on getting Sendmail working for Cygwin. I'm almost done, the devil is in the details... I'm getting the 'Bad file descriptor' system error after building the mail aliases database. The building itself is done successful, but logging the event to the system log fails with this message. Did you mention whether you've installed and configured some syslog service? I have syslogd running from the 'inetutils-server' package. D. -- 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: (call-process ...) hangs in emacs
On 8/5/2014 9:58 AM, Corinna Vinschen wrote: On Aug 5 08:21, Ken Brown wrote: On 8/4/2014 9:45 AM, Corinna Vinschen wrote: ...this, and the fact that fork/exec (vfork == fork on Cygwin) still works nicely in other scenarios points to some problem with the usage of pthread_mutexes in the application may be the culprit. For instance, is it possible that emacs expects the pthread_mutexes in malloc to be ERRORCHECK mutexes? What if you explicitely set them to ERRORCHECK at creation time? That doesn't seem to be the issue, but I think I did find the problem, and it looks like there might be both an emacs bug and a Cygwin bug. Here's the relevant code from emacs's gmalloc.c: pthread_mutex_t _malloc_mutex = PTHREAD_MUTEX_INITIALIZER; pthread_mutex_t _aligned_blocks_mutex = PTHREAD_MUTEX_INITIALIZER; [...] /* Some pthread implementations call malloc for statically initialized mutexes when they are used first. To avoid such a situation, we initialize mutexes here while their use is disabled in malloc etc. */ pthread_mutex_init (_malloc_mutex, NULL); pthread_mutex_init (_aligned_blocks_mutex, NULL); The pthread_mutexes are initialized twice, resulting in undefined behavior according to Posix. That's the emacs bug. That's not the problem. It's not necessary to call pthread_mutex_init on statically initialized mutexes, but it doesn't hurt either. Only when calling pthread_mutex_init twice on the same object it goes downhill, especially when the first incarnation of the mutex was already locked. But simply removing the static initialization doesn't fix the problem. On the other hand, the following patch does seem to fix it, at least in preliminary testing: === modified file 'src/gmalloc.c' --- src/gmalloc.c 2014-03-04 19:02:49 + +++ src/gmalloc.c 2014-08-05 01:35:38 + @@ -490,8 +490,8 @@ } #ifdef USE_PTHREAD -pthread_mutex_t _malloc_mutex = PTHREAD_MUTEX_INITIALIZER; -pthread_mutex_t _aligned_blocks_mutex = PTHREAD_MUTEX_INITIALIZER; +pthread_mutex_t _malloc_mutex; +pthread_mutex_t _aligned_blocks_mutex; int _malloc_thread_enabled_p; static void @@ -526,8 +526,11 @@ initialized mutexes when they are used first. To avoid such a situation, we initialize mutexes here while their use is disabled in malloc etc. */ - pthread_mutex_init (_malloc_mutex, NULL); - pthread_mutex_init (_aligned_blocks_mutex, NULL); + pthread_mutexattr_t attr1, attr2; + pthread_mutexattr_settype (attr1, PTHREAD_MUTEX_NORMAL); + pthread_mutexattr_settype (attr2, PTHREAD_MUTEX_NORMAL); + pthread_mutex_init (_malloc_mutex, attr1); + pthread_mutex_init (_aligned_blocks_mutex, attr2); pthread_atfork (malloc_atfork_handler_prepare, malloc_atfork_handler_parent, malloc_atfork_handler_child); The first hunk avoids the double initialization, but I don't understand why the second hunk does anything. Since PTHREAD_MUTEX_NORMAL is now the default, shouldn't calling pthread_mutex_init with NULL second argument be equivalent to my calls to pthread_mutexattr_settype? Does this indicate a Cygwin bug, or am I misunderstanding something? AFAICS you're missing something. Your pthread_mutexattr_t attr1, attr2 are not initialized. They contain some random values, thus they are not good objects. The calls to pthread_mutexattr_settype as well as the calls to pthread_mutex_init will fail with EINVAL, but you won't see it due to missing error handling, and you end up without mutexes at all. If you call pthread_mutexattr_init before calling pthread_mutexattr_settype the situation shoul;d be the same as before. Thanks for catching my mistake. Your earlier suggestion about explicitly setting the pthread_mutexes to be ERRORCHECK mutexes seems to fix the problem (as long as I remember to call pthread_mutexattr_init). The revised patch is attached. I went back to using both the static and dynamic initializations as in the original code, since you said that's harmless. Angelo and Katsumi, could you test it and see if it solves the problems you reported? If so, I'll issue new emacs releases. Ken === modified file 'src/gmalloc.c' --- src/gmalloc.c 2014-03-04 19:02:49 + +++ src/gmalloc.c 2014-08-05 17:30:18 + @@ -490,8 +490,8 @@ } #ifdef USE_PTHREAD -pthread_mutex_t _malloc_mutex = PTHREAD_MUTEX_INITIALIZER; -pthread_mutex_t _aligned_blocks_mutex = PTHREAD_MUTEX_INITIALIZER; +pthread_mutex_t _malloc_mutex = PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP; +pthread_mutex_t _aligned_blocks_mutex = PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP; int _malloc_thread_enabled_p; static void @@ -526,8 +526,13 @@ initialized mutexes when they are used first. To avoid such a situation, we initialize mutexes here while their use is disabled in malloc etc. */ - pthread_mutex_init (_malloc_mutex, NULL); - pthread_mutex_init (_aligned_blocks_mutex, NULL); + pthread_mutexattr_t attr1,
Re: cannot display man page for /bin/passwd
On Tue, Aug 5, 2014 at 10:48 AM, Larry Hall (Cygwin) wrote: On 08/05/2014 11:09 AM, Doug Henderson wrote: On Tue, Aug 5, 2014 at 2:21 AM, Corinna Vinschen wrote: On Aug 4 13:48, Doug Henderson wrote: snip Did you not see this https://cygwin.com/ml/cygwin/2014-08/msg00097.html and now this? https://cygwin.com/ml/cygwin/2014-08/msg00100.html -- Larry Actually, I did not. I can see the unread message count, but not the messages unless I save the reply I am composing as a draft. With all the RL distractions going on, it took much longer than I expected to compose my reply - something like 3 hours! But you got be looking for a way to pop-out a reply, like I can for a new message. Found it! This should never happen again. Thanks, Doug -- Doug Henderson, Calgary, Alberta, Canada -- 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
[cygstart] optional double slash after scheme for file URIs
Greetings,
Below you may find a trivial patch for the cygstart program (a part of
the cygutils package) for your review:
--- cygstart.c.old 2014-08-05 15:37:49.021062800 +
+++ cygstart.c.new 2014-08-05 14:20:54.318820400 +
@@ -591,8 +591,12 @@
const wchar_t *pWinDir = NULL;
int rc = 0;
- if (strncmp (aPath, file://, 7) == 0)
-aPath += 7;
+ if (strncmp (aPath, file:, 5) == 0)
+{
+ aPath += 5;
+ if (strncmp (aPath, //, 2) == 0)
+ aPath += 2;
+}
#ifdef __CYGWIN__
/* Convert file path from POSIX to Windows, unless it looks like a URL */
if (!strstr (aPath, ://) strncmp (aPath, mailto:;, 7) != 0)
It makes the double slash after the scheme optional for file URIs. So
this error would not happen:
$ cygstart file:/home/ricartj/page.htm
Unable to start 'file:\home\ricartj\page.htm: The specified file was not found.
The reasons for this are enumerated below:
1. Although RFC 1738 explicitly documents the double slash as
mandatory for file URIs (see Section 5), a new working draft is being
proposed:
http://tools.ietf.org/html/draft-kerwin-file-scheme-10
which makes the double slash optional (see Section 2.2).
2. Many browsers already cope with file URIs that do not contain the
double slash, I personally tested this with Firefox and Internet
Explorer. It would be great if cygstart could work like this as well.
Best regards,
--
Juan Ricart
--
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: [cygstart] optional double slash after scheme for file URIs
Chrome and IE cope with these variants just fine:
file:C:/Projects
file:/C:/Projects
file://C:/Projects
file:///C:/Projects
file:C:/Projects
IE doesn't like more than 4 slashes, but Chrome doesn't mind.
Your patch appears to only cover 0 or 2 slashes. How about something
like this instead of checking for //:
// remove all slashes except the last one
while (strncmp(aPath, //, 2) == 0) aPath++;
// path /C:/Projects is invalid, want C:/Projects instead
if (*aPath == '/' *(aPath + 2) == ':') aPath++;
On Tue, Aug 5, 2014 at 1:02 PM, Juan Gabriel Ricart
juangabriel.ric...@gmail.com wrote:
Greetings,
Below you may find a trivial patch for the cygstart program (a part of
the cygutils package) for your review:
--- cygstart.c.old 2014-08-05 15:37:49.021062800 +
+++ cygstart.c.new 2014-08-05 14:20:54.318820400 +
@@ -591,8 +591,12 @@
const wchar_t *pWinDir = NULL;
int rc = 0;
- if (strncmp (aPath, file://, 7) == 0)
-aPath += 7;
+ if (strncmp (aPath, file:, 5) == 0)
+{
+ aPath += 5;
+ if (strncmp (aPath, //, 2) == 0)
+ aPath += 2;
+}
#ifdef __CYGWIN__
/* Convert file path from POSIX to Windows, unless it looks like a URL */
if (!strstr (aPath, ://) strncmp (aPath, mailto:;, 7) != 0)
It makes the double slash after the scheme optional for file URIs. So
this error would not happen:
$ cygstart file:/home/ricartj/page.htm
Unable to start 'file:\home\ricartj\page.htm: The specified file was not
found.
The reasons for this are enumerated below:
1. Although RFC 1738 explicitly documents the double slash as
mandatory for file URIs (see Section 5), a new working draft is being
proposed:
http://tools.ietf.org/html/draft-kerwin-file-scheme-10
which makes the double slash optional (see Section 2.2).
2. Many browsers already cope with file URIs that do not contain the
double slash, I personally tested this with Firefox and Internet
Explorer. It would be great if cygstart could work like this as well.
Best regards,
--
Juan Ricart
--
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
Re: (call-process ...) hangs in emacs
Hi Ken, On Aug 5 13:55, Ken Brown wrote: On 8/5/2014 9:58 AM, Corinna Vinschen wrote: On Aug 5 08:21, Ken Brown wrote: === modified file 'src/gmalloc.c' --- src/gmalloc.c 2014-03-04 19:02:49 + +++ src/gmalloc.c 2014-08-05 01:35:38 + @@ -490,8 +490,8 @@ } #ifdef USE_PTHREAD -pthread_mutex_t _malloc_mutex = PTHREAD_MUTEX_INITIALIZER; -pthread_mutex_t _aligned_blocks_mutex = PTHREAD_MUTEX_INITIALIZER; +pthread_mutex_t _malloc_mutex; +pthread_mutex_t _aligned_blocks_mutex; int _malloc_thread_enabled_p; static void @@ -526,8 +526,11 @@ initialized mutexes when they are used first. To avoid such a situation, we initialize mutexes here while their use is disabled in malloc etc. */ - pthread_mutex_init (_malloc_mutex, NULL); - pthread_mutex_init (_aligned_blocks_mutex, NULL); + pthread_mutexattr_t attr1, attr2; + pthread_mutexattr_settype (attr1, PTHREAD_MUTEX_NORMAL); + pthread_mutexattr_settype (attr2, PTHREAD_MUTEX_NORMAL); + pthread_mutex_init (_malloc_mutex, attr1); + pthread_mutex_init (_aligned_blocks_mutex, attr2); pthread_atfork (malloc_atfork_handler_prepare, malloc_atfork_handler_parent, malloc_atfork_handler_child); The first hunk avoids the double initialization, but I don't understand why the second hunk does anything. Since PTHREAD_MUTEX_NORMAL is now the default, shouldn't calling pthread_mutex_init with NULL second argument be equivalent to my calls to pthread_mutexattr_settype? Does this indicate a Cygwin bug, or am I misunderstanding something? AFAICS you're missing something. Your pthread_mutexattr_t attr1, attr2 are not initialized. They contain some random values, thus they are not good objects. The calls to pthread_mutexattr_settype as well as the calls to pthread_mutex_init will fail with EINVAL, but you won't see it due to missing error handling, and you end up without mutexes at all. If you call pthread_mutexattr_init before calling pthread_mutexattr_settype the situation shoul;d be the same as before. Thanks for catching my mistake. Your earlier suggestion about explicitly setting the pthread_mutexes to be ERRORCHECK mutexes seems to fix the problem (as long as I remember to call pthread_mutexattr_init). The revised patch is attached. I went back to using both the static and dynamic initializations as in the original code, since you said that's harmless. I'm glad to read that, but I'm still a little bit concerned. If your code works with ERRORCHECK mutexes but hangs with NORMAL mutexes, you *might* miss an error case. I'd suggest to tweak the pthread_mutex_lock/unlock calls and log the threads calling it. It looks like the same thread calls malloc from malloc for some reason and it might be interesting to learn how that happens and if it's really ok in this scenario, because it seems to be unexpected by the code. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpnZYfsETNUF.pgp Description: PGP signature
Re: [cygstart] optional double slash after scheme for file URIs
...but that doesn't handle UNC paths. It might be worth looking at
how Chromium does this:
https://github.com/scheib/chromium/blob/master/url/url_parse_file.cc
On Tue, Aug 5, 2014 at 1:21 PM, James Nylen jny...@gmail.com wrote:
Chrome and IE cope with these variants just fine:
file:C:/Projects
file:/C:/Projects
file://C:/Projects
file:///C:/Projects
file:C:/Projects
IE doesn't like more than 4 slashes, but Chrome doesn't mind.
Your patch appears to only cover 0 or 2 slashes. How about something
like this instead of checking for //:
// remove all slashes except the last one
while (strncmp(aPath, //, 2) == 0) aPath++;
// path /C:/Projects is invalid, want C:/Projects instead
if (*aPath == '/' *(aPath + 2) == ':') aPath++;
On Tue, Aug 5, 2014 at 1:02 PM, Juan Gabriel Ricart
juangabriel.ric...@gmail.com wrote:
Greetings,
Below you may find a trivial patch for the cygstart program (a part of
the cygutils package) for your review:
--- cygstart.c.old 2014-08-05 15:37:49.021062800 +
+++ cygstart.c.new 2014-08-05 14:20:54.318820400 +
@@ -591,8 +591,12 @@
const wchar_t *pWinDir = NULL;
int rc = 0;
- if (strncmp (aPath, file://, 7) == 0)
-aPath += 7;
+ if (strncmp (aPath, file:, 5) == 0)
+{
+ aPath += 5;
+ if (strncmp (aPath, //, 2) == 0)
+ aPath += 2;
+}
#ifdef __CYGWIN__
/* Convert file path from POSIX to Windows, unless it looks like a URL */
if (!strstr (aPath, ://) strncmp (aPath, mailto:;, 7) != 0)
It makes the double slash after the scheme optional for file URIs. So
this error would not happen:
$ cygstart file:/home/ricartj/page.htm
Unable to start 'file:\home\ricartj\page.htm: The specified file was not
found.
The reasons for this are enumerated below:
1. Although RFC 1738 explicitly documents the double slash as
mandatory for file URIs (see Section 5), a new working draft is being
proposed:
http://tools.ietf.org/html/draft-kerwin-file-scheme-10
which makes the double slash optional (see Section 2.2).
2. Many browsers already cope with file URIs that do not contain the
double slash, I personally tested this with Firefox and Internet
Explorer. It would be great if cygstart could work like this as well.
Best regards,
--
Juan Ricart
--
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
Re: syslog function: Bad file descriptor
On Aug 5 19:43, D. Boland wrote: Corinna Vinschen wrote: Somehow the two are connected. The alias database (aliases.db) is built from a plain text file (aliases). If I leave the aliases file writable to the sendmail user, I find that the error message strings have been put right into the alias text-file: $ cat /etc/mail/aliases 21sendmail: PID 1848: alias database /etc/mail/aliases rebuilt by smmspsenet: root news: root webmaster: root www: root ftp: root abuse: root noc: root security: root root: SYSTEM 22sendmail: PID 1848: /etc/mail/aliases: 9 aliases, longest 6 bytes, 82 bytes total If I make the 'aliases' file read-only, then the file is not corrupted, but the error occurs. I don't see that this has to do with syslog. There's a writev to fd 3, but you stripped the strace so we don't know what fd 3 is connected to. Also, syslog writes the output to the Windows event log by default, unless you have a syslog daemon running, connected to /dev/log. So I guess we first have to know what fd 3 is connected to, and then how to reproduce the issue. I have the syslogd (inetutils-server package) running as a Windows Service, using cygrunsrv. I attached the complete strace output. The 'syslog' function works fine while running as the cyg_server user, but after a setuid/setgid to the Sendmail 'smmsp' user, it fails. The output is quite large. I put in printf(syslog: %s\n) calls to mark the spots where it happens. Can you produce another strace for the overwriting case (non-R/O aliases) for comparison? Also, can you do the same strace with no syslogd running? It might be necessary to create a few test versions of Cygwin with more debug output, but let's please see these straces first. Thanks, Corinna pgpVge_fCLOja.pgp Description: PGP signature
[ANNOUNCEMENT] Updated: perl-Text-CSV_XS-1.10-1
Version 1.10-1 of perl-Text-CSV_XS has been uploaded. CHANGE LOG == 1.10- 2014-08-02, H.Merijn Brand * Support for scalar ref in out: csv (out = \(my $x = ), ...) * Support for multi-byte sep_char * Simplified the cache coding DESCRIPTION === Text::CSV_XS provides facilities for the composition and decomposition of comma-separated values. An instance of the Text::CSV_XS class will combine fields into a CSV string and parse a CSV string into fields. The module accepts either strings or files as input and support the use of user-specified characters for delimiters, separators, and escapes. CPAN http://search.cpan.org/~hmbrand/Text-CSV_XS/CSV_XS.pm Cheers, Dave. If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, 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
[ANNOUNCEMENT] Updated: perl-Text-CSV_XS-1.10-2 [TEST]
Version 1.10-2 of perl-Text-CSV_XS has been uploaded. This is a test release, built against the test version of perl 5.18.2, and is only available for x86 at this time. CHANGE LOG == 1.10- 2014-08-02, H.Merijn Brand * Support for scalar ref in out: csv (out = \(my $x = ), ...) * Support for multi-byte sep_char * Simplified the cache coding DESCRIPTION === Text::CSV_XS provides facilities for the composition and decomposition of comma-separated values. An instance of the Text::CSV_XS class will combine fields into a CSV string and parse a CSV string into fields. The module accepts either strings or files as input and support the use of user-specified characters for delimiters, separators, and escapes. CPAN http://search.cpan.org/~hmbrand/Text-CSV_XS/CSV_XS.pm Cheers, Dave. If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, 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: Basic question about cygport
On 8/4/2014 8:41 PM, Doug Henderson wrote: On Mon, Aug 4, 2014 at 9:17 PM, Andrew DeFaria wrote: On 8/4/2014 7:52 PM, Larry Hall (Cygwin) wrote: Thankfully, the rough attitude is not held by everyone, though it sometimes has been seen in people who carry platinum watches - and that might encourage its continuation... I like platinum watches. Platinum watches are friends of mine. You sir, are no platinum watch. :-D (I'm afraid I'm dating myself with my artist's interpretation of this quote - http://en.wikipedia.org/wiki/Senator,_you%27re_no_Jack_Kennedy#Transcript). What's a watch? ;-) See https://cygwin.com/goldstars/ where gold stars, gold watches and a platinum watch are awarded to distinguished contributors to the cygwin project. Without the contribution of these folks, this community would be a much poorer place. Sorry I was making a joke about the fact that many people don't wear watches at all anymore. Move along... Nothing to see here... -- Andrew DeFaria http://defaria.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: Basic question about cygport
On 08/05/2014 03:04 PM, Andrew DeFaria wrote: Sorry I was making a joke about the fact that many people don't wear watches at all anymore. And that dates me again. ;-) -- Larry _ 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: syslog function: Bad file descriptor
Corinna Vinschen wrote: Can you produce another strace for the overwriting case (non-R/O aliases) for comparison? Also, can you do the same strace with no syslogd running? It might be necessary to create a few test versions of Cygwin with more debug output, but let's please see these straces first. I attached all three of them in a zipped file. By the way: my previous strace outputs where from an older version of cygwin1.dll. I put a recent one in and did the attached traces: CYGWIN_NT-5.1 dimension 1.7.31s(0.272/5/3) 20140716 11:15:29 i686 Cygwin Daniel sendmail-test.tar.gz Description: GNU Zip compressed data -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: dos2unix 6.0.6-1
CHANGES SINCE LAST RELEASE: === New upstream release. * Bugfix: mac2unix conversion produced corrupted output from UTF-16 input file. * New options -b (keep BOM) and -r (remove BOM). * New translation of the UI messages: Norwegian Bokmaal. homepage: http://waterlan.home.xs4all.nl/dos2unix.html license: 2-clause BSD (FreeBSD) -- Erwin Waterlander http://waterlan.home.xs4all.nl/ -- 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: (call-process ...) hangs in emacs
Ciao, Ken Ken Brown wrote: Angelo and Katsumi, could you test it and see if it solves the problems you reported? for what I can see, with your patch (pthread_mutex.patch), the things work better.. at least the build does not hang and with repeated 'make -j3' it was also completed in Cygwin-1.7.31... :) Ciao, Angelo. -- 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: (call-process ...) hangs in emacs
On Tue, 05 Aug 2014 13:55:31 -0400, Ken Brown wrote: Angelo and Katsumi, could you test it and see if it solves the problems you reported? If so, I'll issue new emacs releases. Thanks. But currently I cannot test it since the autogen.sh script doesn't work as the following. I must make it work, somehow or other... % ./autogen.sh [...] Running 'autoreconf -fi -I m4' ... 0 [main] perl 4508 child_info_fork::abort: address space needed by 'POSIX.dll' (0x2D) is already occupied Can't fork, trying again in 5 seconds at /usr/bin/autoreconf-2.69 line 188. 0 [main] perl 6264 child_info_fork::abort: address space needed by 'POSIX.dll' (0x26) is already occupied Can't fork, trying again in 5 seconds at /usr/lib/perl5/5.14/i686-cygwin-threads-64int/IO/File.pm line 188. [...] rebaseall nor reinstalling of perl and some things doesn't help. : -- 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
missing extern C in sys/file.h
I guess this patch is right.
Rgds
A
--- sys/file.h.Orig 2014-08-05 23:46:27.199694300 -0400
+++ sys/file.h 2014-08-05 23:46:55.919734500 -0400
@@ -39,7 +39,14 @@
#define LOCK_NB0x04/* don't block when
locking */
#define LOCK_UN0x08/* unlock file */
+#ifdef __cplusplus
+extern C
+{
+#endif
extern int flock _PARAMS ((int, int));
+#ifdef __cplusplus
+}
+#endif
#endif
--
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
Updated: openssl-1.0.1h-2
The following packages have been updated in the Cygwin distribution: * openssl-1.0.1h-2 * libopenssl100-1.0.1h-2 * openssl-devel-1.0.1h-2 This release fixes the passwd man page collision introduced with openssl-1.0.1h. If you have the cygwin-doc package installed as well, just update openssl as well as reinstall the cygwin-doc package, then you'll have the original passwd man page back. Have fun, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Updated: perl-Text-CSV_XS-1.10-1
Version 1.10-1 of perl-Text-CSV_XS has been uploaded. CHANGE LOG == 1.10- 2014-08-02, H.Merijn Brand * Support for scalar ref in out: csv (out = \(my $x = ), ...) * Support for multi-byte sep_char * Simplified the cache coding DESCRIPTION === Text::CSV_XS provides facilities for the composition and decomposition of comma-separated values. An instance of the Text::CSV_XS class will combine fields into a CSV string and parse a CSV string into fields. The module accepts either strings or files as input and support the use of user-specified characters for delimiters, separators, and escapes. CPAN http://search.cpan.org/~hmbrand/Text-CSV_XS/CSV_XS.pm Cheers, Dave. If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, 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.
Updated: perl-Text-CSV_XS-1.10-2 [TEST]
Version 1.10-2 of perl-Text-CSV_XS has been uploaded. This is a test release, built against the test version of perl 5.18.2, and is only available for x86 at this time. CHANGE LOG == 1.10- 2014-08-02, H.Merijn Brand * Support for scalar ref in out: csv (out = \(my $x = ), ...) * Support for multi-byte sep_char * Simplified the cache coding DESCRIPTION === Text::CSV_XS provides facilities for the composition and decomposition of comma-separated values. An instance of the Text::CSV_XS class will combine fields into a CSV string and parse a CSV string into fields. The module accepts either strings or files as input and support the use of user-specified characters for delimiters, separators, and escapes. CPAN http://search.cpan.org/~hmbrand/Text-CSV_XS/CSV_XS.pm Cheers, Dave. If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, 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.
Updated: dos2unix 6.0.6-1
CHANGES SINCE LAST RELEASE: === New upstream release. * Bugfix: mac2unix conversion produced corrupted output from UTF-16 input file. * New options -b (keep BOM) and -r (remove BOM). * New translation of the UI messages: Norwegian Bokmaal. homepage: http://waterlan.home.xs4all.nl/dos2unix.html license: 2-clause BSD (FreeBSD) -- Erwin Waterlander http://waterlan.home.xs4all.nl/
