On Fri, 14 Mar 2025 15:18:45 +0100
Corinna Vinschen wrote:
> On Mar 14 21:52, Takashi Yano via Cygwin wrote:
> > On Fri, 14 Mar 2025 13:19:28 +0100
> > Corinna Vinschen wrote:
> > > On Mar 14 20:35, Takashi Yano via Cygwin wrote:
> > > > On Fri, 14 Mar 2025 11:01:25 +0100
> > > > Corinna Vinschen w
On Mar 14 21:52, Takashi Yano via Cygwin wrote:
> On Fri, 14 Mar 2025 13:19:28 +0100
> Corinna Vinschen wrote:
> > On Mar 14 20:35, Takashi Yano via Cygwin wrote:
> > > On Fri, 14 Mar 2025 11:01:25 +0100
> > > Corinna Vinschen wrote:
> > > > I don't think so. I was mulling in circles over this ton
On Fri, 14 Mar 2025 13:19:28 +0100
Corinna Vinschen wrote:
> On Mar 14 20:35, Takashi Yano via Cygwin wrote:
> > On Fri, 14 Mar 2025 11:01:25 +0100
> > Corinna Vinschen wrote:
> > > I don't think so. I was mulling in circles over this tonight
> > > (don't ask me how I slept!) and came to the same
.
Good point. I attach a new proposal. It also doesn't check against
&initialized (becasue that doesn't avoid an overflow into initialized,
but against the last slot of the stack. This also moves pop into
the C++ code and drops its assembler counterpart.
Ok?
THanks,
Corinna
>From 17
On Fri, 14 Mar 2025 11:01:25 +0100
Corinna Vinschen wrote:
> On Mar 14 12:56, Takashi Yano via Cygwin wrote:
> > On Fri, 14 Mar 2025 08:12:36 +0900
> > Takashi Yano wrote:
> > > On Thu, 13 Mar 2025 23:46:49 +0100
> > > Corinna Vinschen wrote:
> > > > I have a slighty changed version. This one treat
On Mar 14 12:56, Takashi Yano via Cygwin wrote:
> On Fri, 14 Mar 2025 08:12:36 +0900
> Takashi Yano wrote:
> > On Thu, 13 Mar 2025 23:46:49 +0100
> > Corinna Vinschen wrote:
> > > I have a slighty changed version. This one treats anything other
> > > than 0, 1 or 2 new addresses on the stack as bug
On Fri, 14 Mar 2025 08:18:41 +0900
Takashi Yano wrote:
> On Fri, 14 Mar 2025 08:12:36 +0900
> Takashi Yano wrote:
> > On Thu, 13 Mar 2025 23:46:49 +0100
> > Corinna Vinschen wrote:
> > > On Mar 13 17:30, Corinna Vinschen via Cygwin wrote:
> > > > On Mar 13 21:31, Takashi Yano via Cygwin wrote:
> >
rig_stackptr can be larger than 2 when
> user code
> signal handler 1
> signal handler 2
> signal handler 3
> signal handler 4
> ret
> ret
> ret
> HERE <= stackptr - orig_stackptr == 3
> ret
> Is this right?
No, I was
On Fri, 14 Mar 2025 08:12:36 +0900
Takashi Yano wrote:
> On Thu, 13 Mar 2025 23:46:49 +0100
> Corinna Vinschen wrote:
> > On Mar 13 17:30, Corinna Vinschen via Cygwin wrote:
> > > On Mar 13 21:31, Takashi Yano via Cygwin wrote:
> > > > What about following patch instead of your sigdelayed patch?
>
On Thu, 13 Mar 2025 23:46:49 +0100
Corinna Vinschen wrote:
> On Mar 13 17:30, Corinna Vinschen via Cygwin wrote:
> > On Mar 13 21:31, Takashi Yano via Cygwin wrote:
> > > What about following patch instead of your sigdelayed patch?
> > > [...]
> > > @@ -1834,6 +1841,26 @@ _cygtls::call_signal_handl
how this may happen.
Apart from that, I attached my patch proposal.
Thanks,
Corinna
>From 588d51915e6e49bbec3ab30aff7f9fe3d4e82744 Mon Sep 17 00:00:00 2001
From: Takashi Yano
Date: Thu, 13 Mar 2025 23:28:53 +0100
Subject: [PATCH] Cygwin: signals: pop return address from signal stack earlier
Comm
On Mar 13 21:31, Takashi Yano via Cygwin wrote:
> On Thu, 13 Mar 2025 20:42:52 +0900
> Takashi Yano wrote:
> > After the commit:
> >
> > commit a942476236b5e39bf30c533d08df7392e326a4c6 (origin/master,
> > origin/main, origin/HEAD)
> > Author: Corinna Vinschen
> > Date: Wed Mar 12 17:17:31 2025
gt; >>>> - call from a signal handler interrupting user space
> > >>>> - call from a signal handler interrupting a system call
> > >>>>
> > >>>> It works as expected ... until the signal count reaches 256. Then
> >
ng a system call
> >>>>
> >>>> It works as expected ... until the signal count reaches 256. Then signals
> >>>> are again only delivered from inside of a system call.
> >>>> [...]
> >>>> Interesting... Hmm... is there some 8-bit
space
- call from a signal handler interrupting user space
- call from a signal handler interrupting a system call
It works as expected ... until the signal count reaches 256. Then signals
are again only delivered from inside of a system call.
[...]
Interesting... Hmm... is there some 8-bit counter
Corinna wrote:
> Just pushed. Try cygwin-3.6.0-0.430.ga942476236b5 in a bit.
I could not get an xterm to come up using cygwin-3.6.0-0.429. But it
works again using cygwin-3.6.0-0.430. I wonder if it was the
swapcontext () problem or something else.
This was on Windows 11.
--
Jim Reisert AD1
r space
> > > - call from a signal handler interrupting user space
> > > - call from a signal handler interrupting a system call
> > >
> > > It works as expected ... until the signal count reaches 256. Then signals
> > > are again only delivered from i
tcase should test the following use cases of setcontext:
> > - call from regular user space
> > - call from a signal handler interrupting user space
> > - call from a signal handler interrupting a system call
> >
> > It works as expected ... until the signal count re
On Mar 12 16:30, Corinna Vinschen via Cygwin wrote:
> Theoretically, a small update to sigdelayed() would fix the issue: ather
> then poing the original IP from the signal stack after calling the
Make that:
Theoretically, a small update to sigdelayed() would fix the issue:
*R*ather then po*p*
l from a signal handler interrupting user space
> - call from a signal handler interrupting a system call
>
> It works as expected ... until the signal count reaches 256. Then signals
> are again only delivered from inside of a system call.
> [...]
> Interesting... Hmm... is ther
n STC, by any chance?
The attached testcase should test the following use cases of setcontext:
- call from regular user space
- call from a signal handler interrupting user space
- call from a signal handler interrupting a system call
It works as expected ... until the signal count reaches 256. The
On Mar 8 12:07, Christian Franke via Cygwin wrote:
> Corinna Vinschen via Cygwin wrote:
> > On Mar 6 13:24, Christian Franke via Cygwin wrote:
> > > Found because 'stress-ng --context 1 ...' always hangs.
> > >
> > > The attached testcase uses the example from Linux swapcontext(3) to call
> > >
Corinna Vinschen via Cygwin wrote:
On Mar 6 13:24, Christian Franke via Cygwin wrote:
Found because 'stress-ng --context 1 ...' always hangs.
The attached testcase uses the example from Linux swapcontext(3) to call the
context functions.
Just tested with 3.5.3 and it doesn't work there, eithe
$ /bin/kill --force 639
> > > >> kill: 639: No such process
> > > >>
> > > >>
> > > >> A similar problem, but without the "error sending signal" message,
> > > >> occurs if the timer is not used but the parent process issues
o continue.
> >
> > If the testcase is assigned to a single core with 'taskset 0x1 ...', it
> > apparently always hangs.
>
> Thanks for the report and the testcase.
> The current implementation of the signal queue has the following problems:
> 1) Signals in the que
not used but the parent process issues SIGSTOP
> > >> SIGALRM SIGCONT ... sequences.
> > > Thanks for the report, especially for the test case. I was able to
> > > easily reproduce the issue. However, I haven't found the cause until
> > > today. I spent 3 days investig
ignal" message,
> >> occurs if the timer is not used but the parent process issues SIGSTOP
> >> SIGALRM SIGCONT ... sequences.
> > Thanks for the report, especially for the test case. I was able to
> > easily reproduce the issue. However, I haven't found the
On Mar 6 13:24, Christian Franke via Cygwin wrote:
> Found because 'stress-ng --context 1 ...' always hangs.
>
> The attached testcase uses the example from Linux swapcontext(3) to call the
> context functions.
Just tested with 3.5.3 and it doesn't work there, either.
So yeah, it's a bug, but i
oid sighandler(int sig)
{
(void)sig;
++sigcnt;
sigflag = 1;
write(1, "[SIGINT]\n", 9);
}
static void waste_time()
{
printf("waste_time: started\n");
int flag = 0;
sigflag = 0;
volatile double x = 1.0;
const int n = 100*1000*1000; // ~5s on i7-14700
9.g3c1308ed890e.x86_64, thanks!
Unfortunately signals may be lost, a new testcase is attached:
$ uname -r
3.6.0-0.419.g3c1308ed890e.x86_64
$ gcc -o lostsig lostsig.c
$ ./lostsig
1157: fork()=1158
SIGALRM x 10
[ALRM]
[ALRM]
[ALRM]
SIGSTOP
[ALRM]
SIGTERM
SIGCONT
waitpid()...
[TERM]
1158: 4 SIGALRM rec
ar 2025 at 12:43, Corinna Vinschen via Cygwin
> > > > wrote:
> > > > >
> > > > > On Feb 28 15:36, Lionel Cons via Cygwin wrote:
> > > > > > We've hit a scalability issue in Cygwin today, the application in
> > > > >
t; >
> > > > On Feb 28 15:36, Lionel Cons via Cygwin wrote:
> > > > > We've hit a scalability issue in Cygwin today, the application in
> > > > > question ran out of POSIX realtime signals (i.e. SIGRTMIN-SIGRTMAX).
> > > > >
> >
gt; > We've hit a scalability issue in Cygwin today, the application in
> > > > question ran out of POSIX realtime signals (i.e. SIGRTMIN-SIGRTMAX).
> > > >
> > > > Could Cygwin support 128 POSIX realtime signals?
> > >
> > > Not possible
On Mar 3 23:07, Lionel Cons via Cygwin wrote:
> On Mon, 3 Mar 2025 at 12:43, Corinna Vinschen via Cygwin
> wrote:
> >
> > On Feb 28 15:36, Lionel Cons via Cygwin wrote:
> > > We've hit a scalability issue in Cygwin today, the application in
> > > questi
On Mon, 3 Mar 2025 at 12:43, Corinna Vinschen via Cygwin
wrote:
>
> On Feb 28 15:36, Lionel Cons via Cygwin wrote:
> > We've hit a scalability issue in Cygwin today, the application in
> > question ran out of POSIX realtime signals (i.e. SIGRTMIN-SIGRTMAX).
> >
>
On Feb 28 15:36, Lionel Cons via Cygwin wrote:
> We've hit a scalability issue in Cygwin today, the application in
> question ran out of POSIX realtime signals (i.e. SIGRTMIN-SIGRTMAX).
>
> Could Cygwin support 128 POSIX realtime signals?
Not possible. sigset_t is an unsigned
We've hit a scalability issue in Cygwin today, the application in
question ran out of POSIX realtime signals (i.e. SIGRTMIN-SIGRTMAX).
Could Cygwin support 128 POSIX realtime signals?
Lionel
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.co
On Mon, 24 Feb 2025 11:29:59 +0100
Christian Franke wrote:
> Found with 'stress-ng --cpu-sched 1':
>
> Testcase (attached):
>
> $ uname -r
> 3.6.0-0.387.g8cebbb2b42bf.x86_64
>
> $ gcc -o timersig timersig.c
>
> $ ./timersig
> 638: fork()=639
> !...!SIGSTOP: Permission de
Found with 'stress-ng --cpu-sched 1':
Testcase (attached):
$ uname -r
3.6.0-0.387.g8cebbb2b42bf.x86_64
$ gcc -o timersig timersig.c
$ ./timersig
638: fork()=639
!...!SIGSTOP: Permission denied
0 [itimer] timersig 639 sig_send: error sending signal 14, pid 639,
pipe
On Mon, 25 Nov 2024 21:23:45 +0900
Takashi Yano wrote:
> On Sun, 24 Nov 2024 01:15:09 +0900
> Takashi Yano wrote:
> > On Sat, 23 Nov 2024 16:53:21 +0100
> > Christian Franke wrote:
> > > Takashi Yano via Cygwin wrote:
> > > > On Wed, 20 Nov 2024 22:43:08 +0900
> > > > Takashi Yano wrote:
> > > >> O
On Sun, 24 Nov 2024 01:15:09 +0900
Takashi Yano wrote:
> On Sat, 23 Nov 2024 16:53:21 +0100
> Christian Franke wrote:
> > Takashi Yano via Cygwin wrote:
> > > On Wed, 20 Nov 2024 22:43:08 +0900
> > > Takashi Yano wrote:
> > >> On Tue, 19 Nov 2024 18:21:52 +0900
> > >> Takashi Yano wrote:
> > >>> On
On Sat, 23 Nov 2024 16:53:21 +0100
Christian Franke wrote:
> Takashi Yano via Cygwin wrote:
> > On Wed, 20 Nov 2024 22:43:08 +0900
> > Takashi Yano wrote:
> >> On Tue, 19 Nov 2024 18:21:52 +0900
> >> Takashi Yano wrote:
> >>> On Tue, 12 Nov 2024 10:53:58 +0100
> >>> Christian Franke wrote:
> F
On Sun, 24 Nov 2024 00:41:15 +0900
Takashi Yano via Cygwin wrote:
> On Sat, 23 Nov 2024 20:53:07 +0900
> Takashi Yano wrote:
> > The patch attached almost solves the problem. However, your test
> > case is paused for tens of seconds, then ends normally.
> >
> > If the code:
> > cpu_set_t c
Takashi Yano via Cygwin wrote:
On Wed, 20 Nov 2024 22:43:08 +0900
Takashi Yano wrote:
On Tue, 19 Nov 2024 18:21:52 +0900
Takashi Yano wrote:
On Tue, 12 Nov 2024 10:53:58 +0100
Christian Franke wrote:
Found with 'stress-ng --cpu-sched' from current stress-ng upstream HEAD:
Testcase (attached):
On Sat, 23 Nov 2024 20:53:07 +0900
Takashi Yano wrote:
> The patch attached almost solves the problem. However, your test
> case is paused for tens of seconds, then ends normally.
>
> If the code:
> cpu_set_t cpus; CPU_ZERO(&cpus);
> CPU_SET(0, &cpus);
> if (sched_setaffinity(get
On Wed, 20 Nov 2024 22:43:08 +0900
Takashi Yano wrote:
> On Tue, 19 Nov 2024 18:21:52 +0900
> Takashi Yano wrote:
> > On Tue, 12 Nov 2024 10:53:58 +0100
> > Christian Franke wrote:
> > > Found with 'stress-ng --cpu-sched' from current stress-ng upstream HEAD:
> > >
> > > Testcase (attached):
> > >
s
[^C]
INT 1
[^C]
INT 2
...
[^C]
INT 21
[^C]
[^C]
INT 22
...
The following run in a second window may not stop the process due to few lost
signals:
for i in {1..100}; do
echo $i; killall -INT longjmpsigs || break; sleep 1
done
The problem does not occur if a regular loop is used
]
INT 22
...
The following run in a second window may not stop the process due to few
lost signals:
for i in {1..100}; do
echo $i; killall -INT longjmpsigs || break; sleep 1
done
The problem does not occur if a regular loop is used instead of
setjmp/longjmp.
Reproducible also with curre
On Tue, 19 Nov 2024 18:21:52 +0900
Takashi Yano wrote:
> On Tue, 12 Nov 2024 10:53:58 +0100
> Christian Franke wrote:
> > Found with 'stress-ng --cpu-sched' from current stress-ng upstream HEAD:
> >
> > Testcase (attached):
> >
> > $ gcc -O2 -o manysignals manysignals.c
> >
> > $ ./manysignals
>
On Tue, 12 Nov 2024 10:53:58 +0100
Christian Franke wrote:
> Found with 'stress-ng --cpu-sched' from current stress-ng upstream HEAD:
>
> Testcase (attached):
>
> $ gcc -O2 -o manysignals manysignals.c
>
> $ ./manysignals
> fork() = 1833
> ...
> fork() = 1848
> ...
> kill(1833, 17)
> ...
> kill(
Found with 'stress-ng --cpu-sched' from current stress-ng upstream HEAD:
Testcase (attached):
$ gcc -O2 -o manysignals manysignals.c
$ ./manysignals
fork() = 1833
...
fork() = 1848
...
kill(1833, 17)
...
kill(1848, 17)
kill(1833, 9)
...
kill(1848, 9)
waitpid(1833, ., 0)
Run this in second ter
On Mon, 15 Jul 2019 09:53:27, Corinna Vinschen wrote:
> On Jul 14 15:19, Houder wrote:
> > .. uhm, just a note in the interest of accuracy ...
> >
> > - standard signals (which include USRSIG1 and USRSIG2) are not queued
> >(traditional signal semantics)
&g
the same signal,
> > > such that the signal should be separately pending on both threads at
> > > the same time, only one of the two signals is actually queued. It
> > > seems that pthread_kill() is ignored if the same signal is already
> > > pending on some other
ately pending on both threads at
> > the same time, only one of the two signals is actually queued. It
> > seems that pthread_kill() is ignored if the same signal is already
> > pending on some other thread.
>
> The current signal mechanism in Cygwin only allows for a signal to
On Jul 6 19:15, Kenton Varda wrote:
> I found a second problem which may or may not be related:
>
> If two threads use pthread_kill() to send each other the same signal,
> such that the signal should be separately pending on both threads at
> the same time, only one of the
On Jul 6 15:46, Kenton Varda wrote:
> Hello Cygwin,
>
> According to the (Linux) man page: "sigpending() returns the set of
> signals that are pending for delivery to the calling thread"
>
> However, on Cygwin, sigpending() seems to return the set of signals
> pen
I found a second problem which may or may not be related:
If two threads use pthread_kill() to send each other the same signal,
such that the signal should be separately pending on both threads at
the same time, only one of the two signals is actually queued. It
seems that pthread_kill() is
Hello Cygwin,
According to the (Linux) man page: "sigpending() returns the set of
signals that are pending for delivery to the calling thread"
However, on Cygwin, sigpending() seems to return the set of signals
pending on any thread, as shown in the attached test program.
Among ot
ndefined. So any behavior seems be OK. I'd still encourage to unify the
> behavior of 32-bit and 64-bit code. (See my other mail.)
You are correct.
For those who like a textbook reference, see:
Chapter 22, section 4 (Hardware-Generated Signals) of The Linux Programming
Interface by Mich
I just saw that the result after returning from a synchronous signal is
undefined. So any behavior seems be OK. I'd still encourage to unify the
behavior of 32-bit and 64-bit code. (See my other mail.)
Best regards
Thomas
Am 26.04.2018 um 13:01 schrieb Houder:
> On Thu, 26 Apr 2018 12:52:54, Thom
Hi
Am 26.04.2018 um 13:01 schrieb Houder:
>
> After the invocation of the handler, the program continues with the code
> that attempts 'to divide by zero'.
>
> As result of that, the handler is invoked again.
This means that the behavior of the test case is incorrect when running
in 32-bit mode
On Thu, 26 Apr 2018 12:52:54, Thomas Zimmermann wrote:
> Hi
>
> Am 26.04.2018 um 12:45 schrieb Houder:
> >> The expected behavior is that an installed signal handler runs exactly
> >> once for a signal and the OS terminates the program if the handler
> >> returns. This works on 32-bit Cygwin. Fro
On 2018-04-26 12:45, Houder wrote:
On Thu, 26 Apr 2018 09:57:59, Thomas Zimmermann wrote:
Hello mailing list,
I noticed that synchronous signals (e.g., SIGSEGV, SIGFPE) appear to
be
broken on 64-bit Cygwin systems. I could not find additional
information
on the mailing list. If this is not
Hi
Am 26.04.2018 um 12:45 schrieb Houder:
>> The expected behavior is that an installed signal handler runs exactly
>> once for a signal and the OS terminates the program if the handler
>> returns. This works on 32-bit Cygwin. From my observation, Cygwin 64
>> differs in the follow ways:
>
> .. u
On Thu, 26 Apr 2018 09:57:59, Thomas Zimmermann wrote:
> Hello mailing list,
>
> I noticed that synchronous signals (e.g., SIGSEGV, SIGFPE) appear to be
> broken on 64-bit Cygwin systems. I could not find additional information
> on the mailing list. If this is not already
On 4/26/2018 9:57 AM, Thomas Zimmermann wrote:
Hello mailing list,
I noticed that synchronous signals (e.g., SIGSEGV, SIGFPE) appear to be
broken on 64-bit Cygwin systems. I could not find additional information
on the mailing list. If this is not already a known problem, you'll find
Hello mailing list,
I noticed that synchronous signals (e.g., SIGSEGV, SIGFPE) appear to be
broken on 64-bit Cygwin systems. I could not find additional information
on the mailing list. If this is not already a known problem, you'll find
some analysis below.
I use Cygwin DLL 2.10 wit
gt; > there's a quick solution, though. This looks like a deadlock
> > > > > situation. The signal definitely got send, I just don't see yet
> > > > > why it's not handled in wait_sig.
> > > >
> > > > Yes, test_pending_signal2.c
_sig.
> > >
> > > Yes, test_pending_signal2.c fails in 2.2.1, though the symptoms
> > > differ: there is no Cygwin process left hanging that cannot be
> > > killed by a Cygwin signal.
> > >
> > > But both tests appear to pass in Cygwin 1.7.9, s
nitely got send, I just don't see yet
> > > why it's not handled in wait_sig.
> >
> > Yes, test_pending_signal2.c fails in 2.2.1, though the symptoms
> > differ: there is no Cygwin process left hanging that cannot be
> > killed by a Cygwin signal.
> >
mptoms
> differ: there is no Cygwin process left hanging that cannot be
> killed by a Cygwin signal.
>
> But both tests appear to pass in Cygwin 1.7.9, so in that sense
> it is a regression, just not a recent one.
The regression here was my original fix. It didn't clear pending
> From: Corinna Vinschen [corinna-cyg...@cygwin.com]
> Sent: Thursday, October 29, 2015 1:02 AM
> On Oct 28 10:14, Corinna Vinschen wrote:
...
> > > Thanks; that was fast! I tried replacing cygwin1.dll with
> > > cygwin1-20151023.dll .
> > >
> > > The original test case now works. I checked some
On Oct 28 10:14, Corinna Vinschen wrote:
> On Oct 27 19:06, John Carey wrote:
> > Sorry for the delay.
> >
> > From: Corinna Vinschen [corinna-cyg...@cygwin.com]
> > Sent: Friday, October 23, 2015 5:55 AM
> > > > I've attached a test case that I *think* gets into the right spot, at
> > > > least f
On Oct 27 19:06, John Carey wrote:
> Sorry for the delay.
>
> From: Corinna Vinschen [corinna-cyg...@cygwin.com]
> Sent: Friday, October 23, 2015 5:55 AM
> > > I've attached a test case that I *think* gets into the right spot, at
> > > least for 64-bit Cygwin 2.0.4. That is, it hangs trying to re
nknown error
-1" while
it hangs (meaning that pthread_kill returned -1 instead of an error number).
> > > > - Multiple pending signals targeting different threads could
> > > > coexist, even if they shared the same signal number. This happens
> > > > o
John? Ping?
On Oct 23 14:55, Corinna Vinschen wrote:
> On Oct 22 02:08, John Carey wrote:
> > > From: Corinna Vinschen [corinna-cyg...@cygwin.com]
> > > Sent: Wednesday, October 21, 2015 4:48 AM
> > > Subject: Re: pthread_kill: signals remain pending af
On Oct 22 02:08, John Carey wrote:
> > From: Corinna Vinschen [corinna-cyg...@cygwin.com]
> > Sent: Wednesday, October 21, 2015 4:48 AM
> > Subject: Re: pthread_kill: signals remain pending after target thread exits
> ...
> > > On Sep 11 18:11, John Carey wrote:
>
> From: Corinna Vinschen [corinna-cyg...@cygwin.com]
> Sent: Wednesday, October 21, 2015 4:48 AM
> Subject: Re: pthread_kill: signals remain pending after target thread exits
...
> > On Sep 11 18:11, John Carey wrote:
> > There seems to be a problem with pthread_k
Hi John,
On Sep 11 18:11, John Carey wrote:
> There seems to be a problem with pthread_kill: a pending signal
> targeting a particular thread prevents other threads from receiving
> signals sharing the same signal number--even after the original target
> thread exits and is joi
There seems to be a problem with pthread_kill: a pending signal targeting a
particular thread prevents other threads from receiving signals sharing the
same signal number--even after the original target thread exits and is joined.
To reproduce the issue:
1. Block signal number S.
2
Greetings, Thomas Wolff!
>>> Run Cygwin Console.
>>> Start mintty from there (without run or cygstart).
>>> stty -a looks normal.
>>> In mintty, sleep 9, then ^C or ^\ or ^Z. None of them works.
>>> Neither can mintty be interrupted from the starting console with ^C.
>> Again, WJFFM
> Again, I see
Am 09.02.2015 um 05:25 schrieb Andrey Repin:
Greetings, Thomas Wolff!
Run Cygwin Console.
Start mintty from there (without run or cygstart).
stty -a looks normal.
In mintty, sleep 9, then ^C or ^\ or ^Z. None of them works.
Neither can mintty be interrupted from the starting console with ^C.
A
Greetings, Thomas Wolff!
> Run Cygwin Console.
> Start mintty from there (without run or cygstart).
> stty -a looks normal.
> In mintty, sleep 9, then ^C or ^\ or ^Z. None of them works.
> Neither can mintty be interrupted from the starting console with ^C.
Again, WJFFM
> Both works with xterm.
Run Cygwin Console.
Start mintty from there (without run or cygstart).
stty -a looks normal.
In mintty, sleep 9, then ^C or ^\ or ^Z. None of them works.
Neither can mintty be interrupted from the starting console with ^C.
Both works with xterm. Not sure, though, whether it's a mintty issue
as i
On Jan 23 10:27, SCOTT Damien wrote:
> > On 1/19/2015 8:10 PM, Corinna Vinschen wrote:
> >
> > >
> > >Well, it was not as complicated as I anticipated. I applied a patch
> > >to cygserver to pull it into the wonderful modern times of per-thread
> > >signalling. I created and uploaded a new dev
> On 1/19/2015 8:10 PM, Corinna Vinschen wrote:
>
> >
> >Well, it was not as complicated as I anticipated. I applied a patch
> >to cygserver to pull it into the wonderful modern times of per-thread
> >signalling. I created and uploaded a new developer snapshot to
> >https://cygwin.com/snapsho
On Jan 19 20:46, Marco Atzeri wrote:
> On 1/19/2015 8:10 PM, Corinna Vinschen wrote:
>
> >
> >Well, it was not as complicated as I anticipated. I applied a patch
> >to cygserver to pull it into the wonderful modern times of per-thread
> >signalling. I created and uploaded a new developer snapsho
On 1/19/2015 8:10 PM, Corinna Vinschen wrote:
Well, it was not as complicated as I anticipated. I applied a patch
to cygserver to pull it into the wonderful modern times of per-thread
signalling. I created and uploaded a new developer snapshot to
https://cygwin.com/snapshots/ with this change
On Jan 19 17:21, Corinna Vinschen wrote:
> On Jan 19 11:38, Corinna Vinschen wrote:
> > On Jan 19 08:29, SCOTT Damien wrote:
> > > [...]
> > > I have included a simplified version of my code below. I usually
> > > don't see any evidence of the SIGUSR1 signal being received by either
> > > of the l
On Jan 19 11:38, Corinna Vinschen wrote:
> On Jan 19 08:29, SCOTT Damien wrote:
> > I have a multi-threaded process running under Cygwin that receives
> > messages from several IPC message queues (built using Cygwin's gcc,
> > version 4.8.3). The listener for each queue runs in its own thread,
> >
On Jan 19 08:29, SCOTT Damien wrote:
> I have a multi-threaded process running under Cygwin that receives
> messages from several IPC message queues (built using Cygwin's gcc,
> version 4.8.3). The listener for each queue runs in its own thread,
> each of which is created from the main thread. Ea
I have a multi-threaded process running under Cygwin that receives messages
from several IPC message queues (built using Cygwin's gcc, version 4.8.3). The
listener for each queue runs in its own thread, each of which is created from
the main thread. Each listener is using a blocking call to ms
Mikulas, ping?
On Nov 28 22:12, Corinna Vinschen wrote:
> On Nov 21 15:43, Corinna Vinschen wrote:
> > I'm going to take a step back for now, and reevaluate what happens
> > before trying to apply even more hacks. Ultimately the problem is that
> > the cygtls area is accessed from other threads (
On Nov 21 15:43, Corinna Vinschen wrote:
> I'm going to take a step back for now, and reevaluate what happens
> before trying to apply even more hacks. Ultimately the problem is that
> the cygtls area is accessed from other threads (mainly the signal
> thread) without locking, and worse, that the
On 2014-11-21 14:36, Corinna Vinschen wrote:
On Nov 21 14:06, Yaakov Selkowitz wrote:
On 2014-11-21 10:06, Corinna Vinschen wrote:
On Nov 21 16:50, Marco Atzeri wrote:
On 11/21/2014 3:43 PM, Corinna Vinschen wrote:
On 32-bit. The rebuild of cygwin1.dll requires large number of packages to
cre
On Nov 21 14:06, Yaakov Selkowitz wrote:
> On 2014-11-21 10:06, Corinna Vinschen wrote:
> >On Nov 21 16:50, Marco Atzeri wrote:
> >>On 11/21/2014 3:43 PM, Corinna Vinschen wrote:
> On 32-bit. The rebuild of cygwin1.dll requires large number of packages to
> create the documentation (includi
On 2014-11-21 10:06, Corinna Vinschen wrote:
On Nov 21 16:50, Marco Atzeri wrote:
On 11/21/2014 3:43 PM, Corinna Vinschen wrote:
On 32-bit. The rebuild of cygwin1.dll requires large number of packages to
create the documentation (including tex and java) and I haven't bloated
Java?!?
FOP is
On Nov 21 16:50, Marco Atzeri wrote:
> On 11/21/2014 3:43 PM, Corinna Vinschen wrote:
> >
> >
>
> >>On 32-bit. The rebuild of cygwin1.dll requires large number of packages to
> >>create the documentation (including tex and java) and I haven't bloated
> >
> >Java?!?
>
> make[3]: [cygwin-ug-net/cyg
On 11/21/2014 3:43 PM, Corinna Vinschen wrote:
On 32-bit. The rebuild of cygwin1.dll requires large number of packages to
create the documentation (including tex and java) and I haven't bloated
Java?!?
make[3]: [cygwin-ug-net/cygwin-ug-net.pdf] Error 127 (ignored)
xsltproc --xinclude ../
[Please don't CC me, just send mail to the list. Thank you]
On Nov 21 15:11, Mikulas Patocka wrote:
> > Do you use a DLL built with optimization by any chance? I wouldn't take
> > the backtraces too serious in that case. For debugging it helps a lot
> > to use a Cygwin DLL built without -O
1 - 100 of 227 matches
Mail list logo
