Re: previously reported test case does not work in Cygwin 1.7.18
Le 30/08/2013 23:32, Christopher Faylor a écrit : On Fri, Aug 30, 2013 at 04:40:44PM +0200, Andreas Steenpa? wrote: I would like to bring the issue described below up again. I have just tested this with Cygwin 1.7.24, and it shows the same behaviour as before, so it seems that this bug still persists. My system is: $ uname -a CYGWIN_NT-6.1-WOW64 zoppo 1.7.24(0.269/5/3) 2013-08-15 11:55 i686 Cygwin This should be fixed in the most recent snapshot. I confirm that this works in Cygwin 1.7.25. Thank you for fixing this. Best regards, Andreas -- 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: previously reported test case does not work in Cygwin 1.7.18
I would like to bring the issue described below up again. I have just tested this with Cygwin 1.7.24, and it shows the same behaviour as before, so it seems that this bug still persists. My system is: $ uname -a CYGWIN_NT-6.1-WOW64 zoppo 1.7.24(0.269/5/3) 2013-08-15 11:55 i686 Cygwin Best regards, Andreas Le 25/04/2013 12:06, Andreas Steenpaß a écrit : I have tried to run the following test case with the newest release: http://cygwin.com/ml/cygwin/2012-12/msg00076.html It used to work after it was fixed, but now it seems to be broken again. Actually, it is even worse than before because now, not even thread 1 catches SIGUSR2: $ uname -a CYGWIN_NT-6.1-WOW64 zoppo 1.7.18(0.263/5/3) 2013-04-19 10:39 i686 Cygwin $ ./testcase1 pid: 3628 thread 1 waiting for SIGUSR1 // from another console, send SIGUSR2, then SIGUSR1 (in this order!) $ kill -SIGUSR2 3628 $ kill -SIGUSR1 3628 // The program catches only SIGUSR1, but not SIGUSR2: thread 1 received SIGUSR1 thread 1 waiting for SIGUSR2 Best regards, Andreas -- 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
previously reported test case does not work in Cygwin 1.7.18
I have tried to run the following test case with the newest release: http://cygwin.com/ml/cygwin/2012-12/msg00076.html It used to work after it was fixed, but now it seems to be broken again. Actually, it is even worse than before because now, not even thread 1 catches SIGUSR2: $ uname -a CYGWIN_NT-6.1-WOW64 zoppo 1.7.18(0.263/5/3) 2013-04-19 10:39 i686 Cygwin $ ./testcase1 pid: 3628 thread 1 waiting for SIGUSR1 // from another console, send SIGUSR2, then SIGUSR1 (in this order!) $ kill -SIGUSR2 3628 $ kill -SIGUSR1 3628 // The program catches only SIGUSR1, but not SIGUSR2: thread 1 received SIGUSR1 thread 1 waiting for SIGUSR2 Best regards, Andreas -- 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: SIGCHLD is not delivered
The test case works with the newest snapshot (20130401). Thanks for the fix! Best regards, Andreas -- 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: SIGCHLD is not delivered
Le 05/04/2013 19:41, Christopher Faylor a écrit : On Fri, Apr 05, 2013 at 07:30:42PM +0200, Andreas Steenpa? wrote: The test case works with the newest snapshot (20130401). Thanks for the fix! Thanks for the feedback. I haven't advertised a fix yet because there is still something not quite right in the snapshots and I haven't had a chance to investigate. Good to know that this symptom is fixed though. Yes, I'm one step further now, but my overall goal, getting to run a new parallel framework for the computer algebra system Singular (www.singular.uni-kl.de), which is also part of the Cygwin distribution, is still not achieved with this fix. I've just checked this. Of course, I'll further investigate from my side and try to provide test cases, but debugging this always takes a lot of time because this framework is quite complex and, well, obviously parallel. So if you know that there is still something wrong, I would greatly appreciate if you could also further investigate from your side. Best regards, Andreas -- 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: SIGCHLD is not delivered
Le 05/04/2013 21:32, Christopher Faylor a écrit : On Fri, Apr 05, 2013 at 09:25:16PM +0200, Andreas Steenpa? wrote: Le 05/04/2013 19:41, Christopher Faylor a ?crit : On Fri, Apr 05, 2013 at 07:30:42PM +0200, Andreas Steenpa? wrote: The test case works with the newest snapshot (20130401). Thanks for the fix! Thanks for the feedback. I haven't advertised a fix yet because there is still something not quite right in the snapshots and I haven't had a chance to investigate. Good to know that this symptom is fixed though. Yes, I'm one step further now, but my overall goal, getting to run a new parallel framework for the computer algebra system Singular (www.singular.uni-kl.de), which is also part of the Cygwin distribution, is still not achieved with this fix. I've just checked this. Of course, I'll further investigate from my side and try to provide test cases, but debugging this always takes a lot of time because this framework is quite complex and, well, obviously parallel. So if you know that there is still something wrong, I would greatly appreciate if you could also further investigate from your side. I can't parse that. I'm going to do why I implied I was going to do. I'm not going to download a package. I'm going to fix some problems that I noticed when trying to fix the reported problem. But that's all I'm asking for. I didn't ask you to download a package. Anyway, this code is not yet included in the package, it's on github at its best. But the hope is on my side that fixing the bugs which you already found will help to increase the stability of what I'm trying to achieve for Singular. Best, Andreas -- 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: SIGCHLD is not delivered
Le 30/03/2013 04:16, Andrey Repin a écrit : Knowing, which VM it is, and what is the container settings in regard to hardware virtualisation support, would be helpful. The admin of this system wrote: VMware 4.1.0 (ESXi 4.1) Host configuration: standard configuration for Windows, 64bit CPU: 1 vCPU, RAM: 4 GB, with VMware tools CPU/MMU virtualization: automatic Best regards, Andreas -- 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: SIGCHLD is not delivered
Le 29/03/2013 14:29, Christopher Faylor a écrit : On Thu, Mar 28, 2013 at 02:30:53PM +0100, Andreas Steenpa? wrote: I have noticed that sometimes SIGCHLD is not delivered when a child process exits. I can reproduce this behaviour reliably under the following, very special circumstances: I've uploaded a new snapshot which seems to fix this problem. Before running it, I could see a rare when I ran your test case in a loop. After, I never saw a hang. Thanks for the test case and please give the snapshot a try. I've installed the newest snapshot and recompiled the test case, but it still hangs on my system. I'm sorry for interfering with your release. Is there any further information I could provide to solve this issue? Just to be sure: $ uname -a CYGWIN_NT-6.1-WOW64 zoppo 1.7.18s(0.263/5/3) 20130329 13:18:55 i686 Cygwin My installation of Windows runs in a virtual machine. Could this maybe influence the race conditions? I've noticed that the resolutions I get with clock_gettime(CLOCK_REALTIME, ...); are quite coarse (a few milliseconds!) in comparison to my Linux system (nanoseconds), or is this a general Cygwin thing? Best regards, Andreas -- 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
SIGCHLD is not delivered
I have noticed that sometimes SIGCHLD is not delivered when a child
process exits. I can reproduce this behaviour reliably under the
following, very special circumstances:
* Immediately before calling 'exit(0);', the child process calls some
command 'system(...);'.
* SIGCHLD is blocked.
* A second thread within the main process waits for SIGCHLD
viasigwaitinfo().
* In this second thread, immediately before calling sigwaitinfo(), a
third thread is created. This happens almost simultaneously to
'system(...); exit(0);' in the child process.
This might sound weird at first, but this happened to me in a use case.
Please check the test case below.The program should just print 'foo' and
exit immediately as it does under Linux. Under Cygwin, it hangs. The
second call of sigwaitinfo() in thread_function() does not return. The
SIGCHLD which should be emitted when the child process exits is not caught.
I use a recent snapshot:
$ uname -a
CYGWIN_NT-6.1-WOW64 zoppo 1.7.18s(0.263/5/3) 20130309 21:57:01 i686 Cygwin
Best regards,
Andreas
test case:
#include stdio.h
#include stdlib.h
#include signal.h
#include pthread.h // compile with -lpthread
void *dummy_function(void *args)
{
}
void *thread_function(void *args)
{
sigset_t sigmask;
sigemptyset(sigmask);
sigaddset(sigmask, SIGUSR1);
sigaddset(sigmask, SIGCHLD);
pthread_t thread2;
sigset_t sigusr1;
sigemptyset(sigusr1);
sigaddset(sigusr1, SIGUSR1);
sigwaitinfo(sigusr1, NULL);
pthread_create(thread2, NULL, dummy_function, NULL);
sigwaitinfo(sigmask, NULL);
wait(NULL);
}
void main()
{
sigset_t sigmask;
sigemptyset(sigmask);
sigaddset(sigmask, SIGUSR1);
sigaddset(sigmask, SIGCHLD);
sigprocmask(SIG_BLOCK, sigmask, NULL);
pid_t pid = fork();
if (pid == 0) { // child process
sigset_t sigusr1;
sigemptyset(sigusr1);
sigaddset(sigusr1, SIGUSR1);
sigwaitinfo(sigusr1, NULL);
system(echo foo);
exit(0);
}
pthread_t thread1;
pthread_create(thread1, NULL, thread_function, NULL);
kill(pid, SIGUSR1);
pthread_kill(thread1, SIGUSR1);
pthread_join(thread1, NULL);
exit(0);
}
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: sigwait() ignores non-thread-specific pending signals
Le 07/12/2012 18:38, Christopher Faylor a écrit :
This should be fixed in CVS and in the upcoming snapshot.
Thank you.I tested the snapshot, and this works now.
I have three more things (please tell me if I should start new threads
for these):
1) When will the next official version of Cygwin be released? I have
written some code for the computer algebra system Singular
(www.singular.uni-kl.de) which relies on the functionality that you just
fixed. We would like to have this code in our next release.
2) Some part of my code uses sigwaitinfo(), an extra thread, and a timer
signal to emulate sigtimedwait() which is missing under Cygwin. I could
contribute my code in order to have sigtimedwait() natively under
Cygwin. Please tell me if you are interested.
3) I noticed another bug related to signals which still remains in the
newest snapshot. Here is a test case:
#include stdio.h
#include signal.h
int main()
{
int signr;
sigset_t sigusr1, sigusr2, pending;
sigemptyset(sigusr1);
sigemptyset(sigusr2);
sigemptyset(pending);
sigaddset(sigusr1, SIGUSR1);
sigaddset(sigusr2, SIGUSR2);
sigprocmask(SIG_BLOCK, sigusr1, NULL);
sigprocmask(SIG_BLOCK, sigusr2, NULL);
printf(pid: %d\n, getpid());
sigwait(sigusr1, signr);
sigpending(pending);
sigwait(sigusr2, signr);
return(0);
}
$ uname -a
CYGWIN_NT-6.1-WOW64 zoppo 1.7.18s(0.263/5/3) 20121207 21:00:18 i686 Cygwin
$ ./test_case
pid: 2640
// In another console, type(in this order!)
$ kill -SIGUSR2 2640
$ kill -SIGUSR1 2640
// Then the program gives:
Segmentation fault (core dumped)
$
The program doesn't crash if I send SIGUSR1 first and then SIGUSR2.
Regards,
Andreas
--
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: sigwait() ignores non-thread-specific pending signals
Le 07/12/2012 02:27, Christopher Faylor a écrit : I don't see any difference between Cygwin and Linux when I run the test program. cgf I re-compiled and ran the test program under Cygwin 1.7.17 as well as on several Linux machines (Debian/Fedora/Gentoo/Ubuntu, kernel versions 2.6.29/2.6.32/3.0.6/3.2.0/3.2.12/3.4.9/3.6.6, different kinds of CPUs etc.) and I definitely see a difference. The difference is that after typing in the commands kill -SIGUSR2 [pid] kill -SIGUSR1 [pid] kill -SIGUSR2 [pid] kill -SIGUSR1 [pid] (in this order!) in another console, the program blocks under Cygwin while it exits normally under Linux. The last output under Cygwin is 'thread 2 waiting for SIGUSR2' while under Linux, one more line 'thread 2 received SIGUSR2' is printed out before the program exits. Regards, Andreas -- 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
sigwait() ignores non-thread-specific pending signals
I have noticed that sigwait() does not return immediately if called in
the following situation:
* One of the signals the command is looking for isalready pending.
* This signal was send to the entire process rather than to a specific
thread.
* sigwait() is called from a thread other than the 'main' thread.
Look at the test case below. The function test_sigwait() is first called
from the 'main' thread and then from another thread created in main().
This should not make a difference here, but the function shows different
behaviour.
My interpretation is that sigwait() simply forgets to look for
non-thread-specific signals which are already pending at the time when
it is called.
Regards,
Andreas
My system is:
$ uname -a
CYGWIN_NT-6.1-WOW64 zoppo 1.7.17(0.262/5/3) 2012-10-19 14:39 i686 Cygwin
Here is an example session (comments preceded by //):
$ ./test_case
pid: 2396
thread 1 waiting for SIGUSR1
// From another console, first send SIGUSR2
// (which should remain pending), then SIGUSR1:
$ kill -SIGUSR2 2396
$ kill -SIGUSR1 2396
// The program catches SIGUSR1 first, then SIGUSR2.
// Finally, a second thread starts waiting for SIGUSR1:
thread 1 received SIGUSR1
thread 1 waiting for SIGUSR2
thread 1 received SIGUSR2
thread 2 waiting for SIGUSR1
// Now the same again: first SIGUSR2, then SIGUSR1:
$ kill -SIGUSR2 2396
$ kill -SIGUSR1 2396
// The program only catches SIGUSR1,
// but it blocks waiting for SIGUSR2:
thread 2 received SIGUSR1
thread 2 waiting for SIGUSR2
// Send SIGUSR2 again:
$ kill -SIGUSR2 2396
// The program exits normally:
thread 2 received SIGUSR2
$
#include stdio.h
#include signal.h
#include pthread.h // compile with -lpthread
void *test_sigwait(void *arg)
{
int *threadnr = (int *)arg;
int signr;
sigset_t sigusr1, sigusr2;
sigemptyset(sigusr1);
sigemptyset(sigusr2);
sigaddset(sigusr1, SIGUSR1);
sigaddset(sigusr2, SIGUSR2);
printf(thread %d waiting for SIGUSR1\n, *threadnr);
sigwait(sigusr1, signr);
printf(thread %d received SIGUSR1\n, *threadnr);
printf(thread %d waiting for SIGUSR2\n, *threadnr);
sigwait(sigusr2, signr);
printf(thread %d received SIGUSR2\n, *threadnr);
}
int main()
{
sigset_t sigmask;
sigemptyset(sigmask);
sigaddset(sigmask, SIGUSR1);
sigaddset(sigmask, SIGUSR2);
sigprocmask(SIG_BLOCK, sigmask, NULL);
printf(pid: %d\n, getpid());
int threadnr = 1;
test_sigwait(threadnr);
pthread_t thread2;
threadnr = 2;
pthread_create(thread2, NULL, test_sigwait, threadnr);
pthread_join(thread2, NULL);
return(0);
}
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
