emacs freezes
Hi there, I am not sure what is the problem here. Emacs is now freezing as soon as I hit a keystoke. Any clues what the problem could be? Cheers, Noah -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
entirely remove cygwin
Hi there, could somebody send me details or a web link to fully uninstall cygwin so I can start over from scratch? Just removing the C:/CYGWIN directory is not enough. everytime I reinstall parts of the OS remain in place. I want to fully start over. Cheers, Noah -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
/etc/group
Hi there, what package do I need to reinstall to get a proper /etc/group ? Cheers, Noah -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
emacs and error emacs: Terminal type cygwin is not defined.
Hi there, how do I easily cure this problem? bash-2.03$ emacs -nw my_filename emacs: Terminal type cygwin is not defined. If that is not the actual type of terminal you have, use the Bourne shell command `TERM=... export TERM' (C-shell: `setenv TERM ...') to specify the correct type. It may be necessary to do `unset TERMINFO' (C-shell: `unsetenv TERMINFO') as well. Cheers, Noah -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
whereis telnet
Hi there, I am trying to figure out where telnet is and/or how to install it? Cheers, Noah -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
recommended initial apps to install
Hi there, is there a list of recommended apps to install upon initially installing cygwin? Cheers, Noah -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: recommended initial apps to install
Okay Larry, I understand. there used to be a page that I cant seem to find that had a list of extra suggestions when installing perl, cpan, and expect module. I cant seem to find that page. I have a pretty good memory what was on it though. Cheer,s Noah Larry Hall (Cygwin) wrote: Noah wrote: Hi there, is there a list of recommended apps to install upon initially installing cygwin? 'setup.exe' will install a default set of apps that's considered a "good base". You don't need to select any additional apps beyond that to have a working Cygwin environment. But there is no "recommended" set of apps beyond that. It depends on your needs. For instance, developers may want one or more selections from the "Devel" category, X enthusiasts may want some selections from the "X11" category, etc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
^M added to directory structure
Okay this is most likely a windows issue but I am dont know how to correct the Problem. Something to do with how windows handled line feeds and new lines. I am running rsync as part of cygwin and I see that a '^M' is tacked on at the end of every directory or a new directory '^M/' is created. What do I need to do to make sure the '^M' is no longer tacked on? Here is a sample line? #!/bin/sh /usr/bin/rsync -avz '/cygdrive/c/My Music/' -e ssh [EMAIL PROTECTED]:/shares/internal/Music/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ^M added to directory structure
Thorsten Kampe wrote: * Noah (Sun, 07 Sep 2008 23:26:57 -0700) Okay this is most likely a windows issue but I am dont know how to correct the Problem. Something to do with how windows handled line feeds and new lines. I am running rsync as part of cygwin and I see that a '^M' is tacked on at the end of every directory or a new directory '^M/' is created. What do I need to do to make sure the '^M' is no longer tacked on? Don't use '^M' in your script good answer. I know that. How do I remove it? Cheers, Noah -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
cant ls
Hi there, I am getting back to hopefully having cygwin working on my server again. currently I am unable to 'ls'. is there something that needs to be installed to get the command 'ls' to work? Cheers, Noah -- 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: Ping: Cygwin libtool / assembler problem with -DPIC
On Tue, Oct 12, 2004 at 03:29:10PM +0200, Gerrit P. Haase wrote: > Gerrit wrote: > > PING! > > > Hello, > > > With GNU as PIC is not an noop, when -DPIC is used to invoke gas the > > generated assembly is broken. I saw this problem with a > > reautoconfiscated version of GMP. This may be unusual, but there was > > libtool used to invoke gas. What do you mean by ``the generated assembly is broken''? Please show the error you encountered. I built gmp-4.1.4 on Cygwin, and it passed all tests. I used the shipped ``configure'', but adding -DPIC is not a new libtool behavior. There was a thread about this general topic awhile ago. That GMP actively uses -DPIC to select the correct assembly came up: http://lists.gnu.org/archive/html/libtool/2003-01/msg00060.html -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Problem logging into ssh
I’ve installed and configured sshd to run as a service under a particular account which is an Administrator. I can ssh in fine as that user. However, if I try to ssh as any other user I get the following error: Last login: Wed May 21 18:58:35 2014 from foo.home /bin/bash: Operation not permitted Connection to tango closed. I’ve found a few threads talking about this issue but none of the details/solutions were either pertinent or worked. Other details: Windows Server 2008 R2 Cygwin 1.7.29(0.272/5/3) CYGWIN_NT-6.1-WOW64 OpenSSH 6.6p1-1 TIA, -Noah -- 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: cygserver - Postgres Multiple connection Load Testing - Inifinte Loop
On Tue, Aug 03, 2004 at 12:06:12PM +0200, Corinna Vinschen wrote:
> On Aug 2 20:33, sarbx-cygwin6...@mailblocks.com wrote:
> > This time around, cygserver does not eat CPU. But after 5 to 6
> > concurrent
> > connections nothing seem to work, looks kind of hung. There is no
> > activity in the Postgres
> > log file. Opening a new database connection also hangs. There is no
> > activity on the machine.
> Any chance to create a simple testcase which uncovers that behaviour
> without involving a whole database system?
Attached test program reproduces it on Cygwin 2.7.0, Cygwin 1.7.5, and a few
intermediate versions. The program creates sixteen processes that each
perform a tight loop over the following:
- select one of four semaphores
- reduce semaphore's value from 1 to 0 ("lock" it)
- raise semaphore's value from 0 to 1 ("unlock" it)
On GNU/Linux, AIX, and Solaris, the processes keep busy and finish one million
lock/unlock cycles apiece in a few minutes. On Cygwin, they hang within a few
seconds and under one hundred cycles apiece. At that point, cygserver is
unresponsive to other clients; for example, "strace /bin/true", opening a new
Cygwin terminal, "cat /proc/sysvipc/sem" and "cygserver -S" all hang. In most
tests, cygserver was not consuming CPU while unresponsive.
Thanks,
nm
/*
* Demonstrate cygserver hang under concurrent sysv semaphore traffic. Run
* without arguments. Output will cease within a few seconds, and cygserver
* will be unresponsive to all clients.
*
* This is compatible with default cygserver settings; it uses a single
* semaphore set of four semaphores.
*/
#include
#include
#include
#include
#include
#include
#include
#include
#define SEM_KEY 0x631a2c3e
#define N_WORKER 16
#define N_SEMA (N_WORKER/4)
#define N_CYCLE 100
union semun
{
int val;
struct semid_ds *buf;
unsigned short *array;
};
static int print_every = 1;
/* In parallel, N_WORKER processes run this function. */
static int do_worker(int ordinal, int set)
{
int i;
struct sembuf op;
printf("start worker %d\n", ordinal);
fflush(stdout);
op.sem_flg = 0;
for (i = 1; i <= N_CYCLE; i++)
{
op.sem_num = random() % N_SEMA;
op.sem_op = -1;
if (0 > semop(set, &op, 1))
{
perror("semop");
return 1;
}
op.sem_op = 1;
if (0 > semop(set, &op, 1))
{
perror("semop");
return 1;
}
if (i % print_every == 0)
{
printf("worker %d: %d cycles elapsed\n", ordinal, i);
fflush(stdout);
}
}
return 0;
}
int main(int argc, char **argv)
{
int status = 1, set, i, child_status;
if (argc == 2)
print_every = atoi(argv[1]);
else if (argc != 1)
{
fprintf(stderr, "Usage: sema_parallel [print-every-N]\n");
return status;
}
puts("semget");
fflush(stdout);
set = semget(SEM_KEY, N_SEMA, IPC_CREAT | 0600);
if (set == -1)
{
perror("semget");
return status;
}
puts("SETVAL");
fflush(stdout);
for (i = 0; i < N_SEMA; i++)
{
union semun s;
s.val = 1;
if (0 > semctl(set, i, SETVAL, s))
{
perror("semctl(SETVAL)");
goto cleanup;
}
}
for (i = 0; i < N_WORKER; i++)
{
pid_t pid;
pid = fork();
switch (pid)
{
case -1:
perror("fork");
goto cleanup;
case 0:
return do_worker(i, set);
}
}
status = 0;
cleanup:
while (wait(&child_status) != -1)
;
if (errno != ECHILD)
{
perror("wait");
status = 1;
}
if (0 > semctl(set, 0, IPC_RMID))
{
perror("semtctl(IPC_RMID)");
status = 1;
}
return status;
}
--
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: cygserver - Postgres Multiple connection Load Testing - Inifinte Loop
On Fri, Mar 24, 2017 at 06:11:01PM +0100, Corinna Vinschen wrote:
> - cygserver is using a defined number of threads in a thread pool for
> application requests. Every request is added to a request submission
> queue and handled by the next free thread in the pool.
>
> The default number of threads in the pool is 10. Each wait for a
> semaphore is blocking one thread. If more than the number of threads
> in the pool are supposed to wait on a semaphore the pool starves.
Interesting. I can confirm that, without updating software, "cygserver -r 40"
fixes both my self-contained test and my PostgreSQL test case. Folks can use
that workaround in released-version installations.
> So what I did now is to allow cygserver to raise the number of worker
> threads on demand. That is, if a request is in the queue and all
> worker threads are busy, just create a new one.
>
> There's no way yet to drop threads again, but this should be a minor
> problem in scenarions which really have a lot of contention.
Agreed. This is nicer.
> I pushed a patchset now, and uploaded new developer snapshots for
> testing to https://cygwin.com/snapshots/
> Please give it a try
Self-contained test case results look good:
cygwin-20170321.tar.xz "cygserver -r40": ok
cygwin-20170324.tar.xz "cygserver -r40": ok
cygwin-20170321.tar.xz "cygserver -r10": freezes (expected)
cygwin-20170324.tar.xz "cygserver -r10": ok; cygserver output concludes with
"cygserver: All threads busy, added one (now 21)".
I then tried my PostgreSQL test case ("pgbench -i -s 50" once to setup, then
"pgbench -S -j2 -c16 -T900 -P5" to test):
cygwin-20170321.tar.xz "cygserver -r40": ok for >3600s
cygwin-20170324.tar.xz "cygserver -r40": limited freeze in <1000s; no
cygserver output
cygwin-20170321.tar.xz "cygserver -r10": classic freeze in <1000s (expected)
cygwin-20170324.tar.xz "cygserver -r10": limited freeze in <1000s; no
cygserver output for most of the run, then output concluding with
"cygserver: All threads busy, added one (now 15)" just before the freeze
I call the cygwin-20170324 freezes "limited" because the symptoms differ from
the classic freeze I described upthread. "strace /bin/true" and "cat
/proc/sysvipc/sem" do not hang, but every PostgreSQL backend process is stuck
waiting on a synchronization primitive.
I can distill another self-contained test case for the limited freeze seen in
cygwin-20170324, but that make take awhile. I'm sending this early report so
you're aware of the possible regression in cygwin-20170324.
Thanks,
nm
--
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: cygserver - Postgres Multiple connection Load Testing - Inifinte Loop
On Tue, Mar 28, 2017 at 01:26:52AM -0400, Noah Misch wrote:
> On Fri, Mar 24, 2017 at 06:11:01PM +0100, Corinna Vinschen wrote:
> > I pushed a patchset now, and uploaded new developer snapshots for
> > testing to https://cygwin.com/snapshots/
>
> > Please give it a try
> I call the cygwin-20170324 freezes "limited" because the symptoms differ from
> the classic freeze I described upthread. "strace /bin/true" and "cat
> /proc/sysvipc/sem" do not hang, but every PostgreSQL backend process is stuck
> waiting on a synchronization primitive.
>
> I can distill another self-contained test case for the limited freeze seen in
> cygwin-20170324, but that make take awhile. I'm sending this early report so
> you're aware of the possible regression in cygwin-20170324.
I'm attaching a new test program that demonstrates the regression. My previous
test program created sixteen processes that each picked a random semaphore to
lock. Now, each process picks two semaphores and locks them in order. This
proceeds smoothly on GNU/Linux and on cygwin-20170321.tar.xz "cygserver -r 40".
It freezes within one second on cygwin-20170324.tar.xz "cygserver -r 40".
/*
* Demonstrate cygserver bug introduced in cygwin-20170324.tar.xz snapshot. Run
* without arguments. Test against "cygserver -r 40" to get enough threads.
* This is otherwise compatible with default cygserver settings; it uses a
* single semaphore set of eight semaphores.
*
* Output will cease within a few seconds. On older cygserver and non-Cygwin
* systems, it will run to completion.
*/
#include
#include
#include
#include
#include
#include
#include
#include
#define SEM_KEY 0x631a2c3f
#define N_WORKER 16
#define N_SEMA (N_WORKER/2)
#define N_CYCLE 100
union semun
{
int val;
struct semid_ds *buf;
unsigned short *array;
};
static int print_every = 1;
static int lock(int set, unsigned short sem_num)
{
struct sembuf op;
op.sem_num = sem_num;
op.sem_op = -1;
op.sem_flg = 0;
if (0 > semop(set, &op, 1))
{
perror("semop");
return 1;
}
return 0;
}
static int unlock(int set, unsigned short sem_num)
{
struct sembuf op;
op.sem_num = sem_num;
op.sem_op = 1 ; /* only difference vs. lock() */
op.sem_flg = 0;
if (0 > semop(set, &op, 1))
{
perror("semop");
return 1;
}
return 0;
}
/* In parallel, N_WORKER processes run this function. */
static int do_worker(int ordinal, int set)
{
int i;
printf("start worker %d\n", ordinal);
fflush(stdout);
for (i = 1; i <= N_CYCLE; i++)
{
unsigned short s0, s1;
/* Pick two non-identical semaphore numbers. */
s0 = random() % N_SEMA;
do { s1 = random() % N_SEMA; } while (s0 == s1);
/* Lock the lower one first, thereby preventing deadlock. */
if (lock(set, s0 < s1 ? s0 : s1) || lock(set, s0 < s1 ? s1 : s0)
|| unlock(set, s0) || unlock(set, s1))
return 1;
if (i % print_every == 0)
{
printf("worker %d: %d cycles elapsed\n", ordinal, i);
fflush(stdout);
}
}
return 0;
}
int main(int argc, char **argv)
{
int status = 1, set, i, child_status;
if (argc == 2)
print_every = atoi(argv[1]);
else if (argc != 1)
{
fprintf(stderr, "Usage: sema_two [print-every-N]\n");
return status;
}
puts("semget");
fflush(stdout);
set = semget(SEM_KEY, N_SEMA, IPC_CREAT | 0600);
if (set == -1)
{
perror("semget");
return status;
}
puts("SETVAL");
fflush(stdout);
for (i = 0; i < N_SEMA; i++)
{
union semun s;
s.val = 1;
if (0 > semctl(set, i, SETVAL, s))
{
perror("semctl(SETVAL)");
goto cleanup;
}
}
for (i = 0; i < N_WORKER; i++)
{
pid_t pid;
pid = fork();
switch (pid)
{
case -1:
perror("fork");
goto cleanup;
case 0:
return do_worker(i, set);
}
}
status = 0;
cleanup:
while (wait(&child_status) != -1)
;
if (errno != ECHILD)
{
perror("wait");
status = 1;
}
if (0 > semctl(set, 0, IPC_RMID))
{
perror("semtctl(IPC_RMID)");
status = 1;
}
return status;
}
--
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
Python 3.7.1
Hi All, Sorry if this has been answered somewhere already - I checked the FAQ/StackExchange/Quora and didn't find anything, so coming to the mailing list as a last resort. I was wondering if it's possible to install the latest version of python for Cygwin - all I can find right now is 3.6.4. I can't find it in the library, but is it possible to still use the new version somehow? Maybe routing it to a different python installation or somehow installing from command line? Best, Noah -- 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: cygserver - Postgres Multiple connection Load Testing - Inifinte Loop
On Sat, Apr 01, 2017 at 10:36:24PM -0400, Noah Misch wrote: > On Tue, Mar 28, 2017 at 01:26:52AM -0400, Noah Misch wrote: > > On Fri, Mar 24, 2017 at 06:11:01PM +0100, Corinna Vinschen wrote: > > > I pushed a patchset now, and uploaded new developer snapshots for > > > testing to https://cygwin.com/snapshots/ > > > > > Please give it a try > > > I call the cygwin-20170324 freezes "limited" because the symptoms differ > > from > > the classic freeze I described upthread. "strace /bin/true" and "cat > > /proc/sysvipc/sem" do not hang, but every PostgreSQL backend process is > > stuck > > waiting on a synchronization primitive. > > > > I can distill another self-contained test case for the limited freeze seen > > in > > cygwin-20170324, but that make take awhile. I'm sending this early report > > so > > you're aware of the possible regression in cygwin-20170324. > > I'm attaching a new test program that demonstrates the regression. My > previous > test program created sixteen processes that each picked a random semaphore to > lock. Now, each process picks two semaphores and locks them in order. This > proceeds smoothly on GNU/Linux and on cygwin-20170321.tar.xz "cygserver -r > 40". > It freezes within one second on cygwin-20170324.tar.xz "cygserver -r 40". I suggest reverting the cygwin-20170324 cygserver changes for now. Older versions can be configured to have reliable sysv semaphores, but I think no settings render sysv semaphores reliable in Cygwin 2.8.0. What do you think? -- 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
Signal delivered while blocked
The attached demonstration program blocks signals (with sigprocmask()) to
achieve mutual exclusion between signal handlers. It aborts upon receipt of a
blocked signal. On "CYGWIN_NT-10.0 2.7.0(0.306/5/3) 2017-02-12 13:18 x86_64",
signals regularly arrive despite being blocked. Essential parts of the
program include handling two signal numbers and having handlers run for at
least 1-2ms; this problem goes away if I remove one of those attributes.
GNU/Linux, AIX, Solaris, and "CYGWIN_NT-6.0 1.7.27(0.271/5/3) 2013-12-09 11:57
i686" never deliver a blocked signal to this program. I think this Cygwin
behavior is non-conforming.
PostgreSQL trouble prompted this report; the demonstration program is based on
the "postmaster" architecture. postmaster SIGCHLD and SIGUSR1 handlers block
most signals, and they cannot cope with interrupts from blocked signals.
Thanks,
nm
/*
* Demonstrate improper delivery of a blocked signal.
*
* This program prints "ERROR: already forbidden" and aborts within one
* second on this configuration (uname -srvm):
* CYGWIN_NT-10.0 2.7.0(0.306/5/3) 2017-02-12 13:18 x86_64
*
* It runs indefinitely (>600s) without trouble on these configurations:
* CYGWIN_NT-6.0 1.7.27(0.271/5/3) 2013-12-09 11:57 i686
* Linux 3.10.0-514.16.1.el7.x86_64 #1 SMP Wed Apr 12 15:04:24 UTC 2017
x86_64 [CentOS 7]
* AIX 7100-03-02-1412
* SunOS 5.10 Generic_147147-26 sun4u
*/
#include
#include
#include
#include
#include
#include
static sigset_t block, unblock;
static sig_atomic_t sigblocked = 0; /* Have I blocked signals? */
static char *stack_base;
static sigjmp_buf jmp;
static void
sigforbid(void)
{
const char errmsg[] = "ERROR: already forbidden\n";
if (sigprocmask(SIG_SETMASK, &block, NULL) != 0)
perror("sigprocmask");
if (sigblocked == 1)
{
write(2, errmsg, sizeof(errmsg) - 1);
abort();
}
sigblocked = 1;
}
static void
sigpermit(void)
{
const char errmsg[] = "ERROR: already permitted\n";
if (sigblocked == 0)
{
write(2, errmsg, sizeof(errmsg) - 1);
abort();
}
sigblocked = 0;
if (sigprocmask(SIG_SETMASK, &unblock, NULL) != 0)
perror("sigprocmask");
}
/*
* Start fresh in main() when the stack gets too deep. This is not essential
* to the test, but it allows for long runs without huge RLIMIT_STACK.
*/
static void
clear_stack_if_needed(void)
{
char stack_position;
ptrdiff_t stack_usage;
stack_usage = stack_base - &stack_position;
if (stack_usage < 0)
stack_usage = -stack_usage;
if (stack_usage > 1024 * 1024)
{
puts("releasing excess stack");
sigblocked = 1;
siglongjmp(jmp, 1);
}
}
static void
handler(int arg)
{
sigforbid();
clear_stack_if_needed();
/* wait for extra signal to arrive, after 1-2ms */
usleep(5000);
sigpermit();
}
int main(int argc, char **argv)
{
char stack_position;
/* initial signal mask setup */
sigemptyset(&unblock);
sigfillset(&block);
sigdelset(&block, SIGTRAP);
sigdelset(&block, SIGABRT);
sigdelset(&block, SIGILL);
sigdelset(&block, SIGFPE);
sigdelset(&block, SIGSEGV);
sigdelset(&block, SIGBUS);
sigdelset(&block, SIGSYS);
sigdelset(&block, SIGCONT);
sigforbid();
/* Register signal handlers. Problem somehow requires two signals. */
{
struct sigaction act, oact;
act.sa_handler = handler;
sigemptyset(&act.sa_mask);
act.sa_flags = 0;
if (sigaction(SIGUSR1, &act, &oact) != 0)
perror("sigaction");
if (sigaction(SIGCHLD, &act, &oact) != 0)
perror("sigaction");
}
/* start a child to inundate me with signals */
{
pid_t pid, ppid;
pid = fork();
switch (pid)
{
case -1:
perror("fork");
return 1;
case 0:
ppid = getppid();
printf("pid=%d inundating pid=%d with SIGUSR1
and SIGCHLD\n",
getpid(), ppid);
while (kill(ppid, random() % 2 ? SIGUSR1 :
SIGCHLD) == 0)
;
puts("child done");
return 0;
}
}
/* loop forever while we receive signals */
stack_base = &stack_position;
sigsetjmp(jmp, 1);
for (;;)
{
sigpermit();
usleep(100
Re: Signal delivered while blocked
On Fri, Aug 04, 2017 at 11:58:51AM -0700, Kaz Kylheku wrote: > On 04.08.2017 10:02, Corinna Vinschen wrote: > >On Aug 4 00:44, Noah Misch wrote: > >>The attached demonstration program blocks signals (with sigprocmask()) > >>to > >>achieve mutual exclusion between signal handlers. It aborts upon > >>receipt of a > >>blocked signal. On "CYGWIN_NT-10.0 2.7.0(0.306/5/3) 2017-02-12 13:18 > >>x86_64", > >>signals regularly arrive despite being blocked. Essential parts of the > >>program include handling two signal numbers and having handlers run for > >>at > >>least 1-2ms; this problem goes away if I remove one of those > >>attributes. > >>GNU/Linux, AIX, Solaris, and "CYGWIN_NT-6.0 1.7.27(0.271/5/3) > >>2013-12-09 11:57 > >>i686" never deliver a blocked signal to this program. I think this > >>Cygwin > >>behavior is non-conforming. > > > >Thanks for the testcase. I debugged this a while today but the problem > >is far from trivial, apparently. Don't hold your breath for a quick > >solution. Understood. Thanks for studying it. > The test case depends on accesses to the global variable sigblocked not > to be reordered w.r.t. siggprocmask calls. > > It is important that the variable not be set to 1 until after the signals > are > blocked, and be reset to 0 until after they are unblocked. > > Thus, the variable should be declared volatile. Agreed, but ... > Although I would be surprised if this were actually happening ... indeed, that didn't change the result. > Also, related remarks: for the reason that we can't factor out compiler > behavior, with absolute certainty, it would be good to mention not only > the system versions but also GCC. The compiler differs, obviously, > between Cygwin 1.7 and 2.7; not to mention that the case is reported > against i686 of the one, and x86_74 of the other. The Cygwin 2.7 system has gcc-core 5.4.0-1. The unaffected Cygwin 1.7 system has gcc-core 4.8.2-2. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Signal delivered while blocked
On Mon, Aug 14, 2017 at 08:03:07AM +0200, Houder wrote: > On Fri, 4 Aug 2017 00:44:45, Noah Misch wrote: > > The attached demonstration program blocks signals (with sigprocmask()) to > > achieve mutual exclusion between signal handlers. It aborts upon receipt > > of a > > blocked signal. On "CYGWIN_NT-10.0 2.7.0(0.306/5/3) 2017-02-12 13:18 > > x86_64", > > signals regularly arrive despite being blocked. Essential parts of the > > program include handling two signal numbers and having handlers run for at > > least 1-2ms; this problem goes away if I remove one of those attributes. > > GNU/Linux, AIX, Solaris, and "CYGWIN_NT-6.0 1.7.27(0.271/5/3) 2013-12-09 > > 11:57 > > i686" never deliver a blocked signal to this program. I think this Cygwin > > behavior is non-conforming. > I do not think that Cygwin is the problem here; your code is the problem > here, I believe. > > Please, study, for example, chapters 20 and 21 of LPI (Linux Programming > Interface by Michael Kerrisk). > > (20.10 The Signal Mask (Blocking Signal Delivery) > (20.13 Changing Signal Dispositions: sigaction()) > > You cannot use sigprocmask() like you do; you cannot use SIG_SETMASK as > a parameter in sigprocmask() within the context of a handler. What words in those chapters prompted your conclusion? I see nothing in 20.10 or 20.13 about contextual restrictions on SIG_SETMASK. Posix mentions no such restrictions in its sigprocmask() page, and Posix does say: The following table defines a set of functions that shall be async-signal-safe. Therefore, applications can call them, without restriction, from signal-catching functions. ... sigprocmask() -- http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html > Cygwin exhibits misbehaviour in case of your code, because it is slower > than Linux; however, the code is also wrong for Linux. > > The misbehaviour occurs as result of nested interrupts in case of your > code (yes, nested interrupts are possible with Linux/Unix!). > However your code does not experience nesting under Linux, because, as > I said, Linux is faster than Cygwin. My code *does* experience signal handler nesting on Linux. In fact, handlers nest far more quickly than they do under Cygwin. However, all its nesting under Linux takes place outside the sigprocmask()-bounded critical section. The algorithm that inspired this test case tolerates that nesting, but it does not tolerate nesting within the critical section. > The simplest way to exclude one signal from another, is to specify the > signal (or signals) in the sa_mask of the sigaction parameter ... That is true. However, as you discovered in your other thread, it is not an effective workaround for $SUBJECT. nm -- 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: Signal delivered while blocked
On Sun, Aug 20, 2017 at 02:18:45PM +0200, Houder wrote:
> On 2017-08-19 10:01, Noah Misch wrote:
> >What words in those chapters prompted your conclusion? I see nothing in
> >20.10 or 20.13 about contextual restrictions on SIG_SETMASK. Posix
> >mentions no such restrictions in its sigprocmask() page, and Posix does
> >say:
> Keep in mind, that I replied to your post after I had executed your code on
> Linux (and had a hard look at your code).
>
> I was astonished to see the 'run-away' stack on Linux ...
>
> ("that cannot be correct", was my thinking)
>
> I should have written in my previous reply:
>
> "you cannot make use of SIG_SETMASK in sigprocmask() within the context
> of a handler", IN THE WAY YOU DO IT"
> or
> "in the body of a signal handler, one cannot modify the signal mask w/o
> knowing what it was at the beginning"
>
> 1. when a signal handler is entered, the kernel will (usually) have added
> the signal number, associated to the handler, to the mask
> 2. the execution of a handler may be nested within the execution of another
>
> Consequently, one does not know what the signal mask is at the beginning of
> the critical section in the handler.
>
> That is why you want to save the current signal mask when modifying it (at
> the start of the critical section).
>
> At the end of the critical section, one should restore the old signal mask,
> or test it in case one want to revert the signal mask "by hand".
>
> Take a look at listing 20-5 in LPI.
If the test program has undefined behavior according to Posix, I want to know
that. If the test program can cause $SUBJECT according to Posix, I want to
know that.
Following your advice above would not remove undefined behavior or prevent
$SUBJECT. It would make the signal-using software more maintainable and
reduce the risk of consuming all stack space. Those are good goals for
authors to pursue, but this thread is about delivery of blocked signals.
--
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
