> From: Corinna Vinschen [corinna-cyg...@cygwin.com]
> Sent: Monday, November 02, 2015 9:58 AM
> On Nov 2 15:18, Corinna Vinschen wrote:
> > On Oct 29 16:16, John Carey wrote:
> > > > From: Corinna Vinschen [corinna-cyg...@cygwin.com]
> > > > Sent: Thursd
signal definitely 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.
But both tests appear to pass in Cygwin
period.
> > >
> > > That requires to extend the handling for pending signals. That's
> > > a rather bigger task...
> >
> > Yeah. It's nice if threads don't interfere with each other, but this
> > part would indeed be harder to chan
> 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
(Ubuntu 14.04.3),
where I can generate two signals for two different threads, then sleep for a
bit in each target thread, and finally have each thread receive its signal with
sigwait()--neither signal is lost during the sleeping period.
-- John Carey
--
Problem reports: http://cygwin.com
On Sep 14 12:02, Corinna Vinschen wrote:
> True. Implementing a full replacement for SetCurrentDirectory as in
> your PoC is still an option. However, I can't do that anymore since
> I'm tainted by reading your code. If you would contemplate to sign
> a copyright assignment(**), we could create
On Sep 14 09:11, Corinna Vinschen wrote:
> I applied the below patch to Cygwin CVS and it appears to work nicely.
> The only potential race I can think of is, if another thread of the same
> Cygwin process calls SetCurrentDirectory. I'm inclined to let this
> situation slip through the cracks sinc
On Sep 14 01:12, Corinna Vinschen wrote:
> On Sep 13 19:47, John Carey wrote:
> > On Sep 11 03:30, Corinna Vinschen:
> > Anyway, it looks to me as if overwriting the path in an existing
> > VistaCwd instance would confuse RtlGetCurrentDirectory_U() and
> > probably othe
On Sep 13, John Carey wrote:
> It's not one of those, or even the subroutine that those share. I don't know
> how they relate.
...
(incorrect quotation omitted)
My apologies for using the wrong quotation format. Sorry!
-- John
--
Problem reports: http://cygwin.com/p
On Sep 13 12:47, John Carey wrote:
> On Sep 11 03:30, Corinna Vinschen:
> > Can't we find Cwd by scanning the .data segment of ntdll.h for the
> > address we inferred from the Params.CurrentDirectoryName.Buffer value?
>
> Nice; that might work. But there would need to
On Sep 11 03:30, Corinna Vinschen:
> On Sep 11 00:12, John Carey wrote:
> > The proof-of-concept code follows (and is also attached). It includes
> > an analysis of what is going on--to the extent that I know what is going
> > on, of course. Please let me know what you thi
On Sep 04 02:26 Corinna Vinschen wrote:
> On Sep 3 16:18, John Carey wrote:
> > On Sep 03 12:37 Corinna Vinschen wrote:
> > > On Sep 2 23:32, John Carey wrote:
> > > > In Aug 17 10:15, Corinna Vinschen wrote:
> > > > > I just released 1.7.6-1.
&g
On Sep 04 01:50 Corinna Vinschen wrote:
> On Sep 3 17:19, John Carey wrote:
> > A user mount whose only non-default option is "bind"
> > cannot be unmounted if its target is a system mount;
> > please see the end of this email for a test case.
> >
> > I
A user mount whose only non-default option is "bind"
cannot be unmounted if its target is a system mount;
please see the end of this email for a test case.
It looks to me as if the MOUNT_SYSTEM bit is copied from
the bind target by mount() in winsup/cygwin/mount.cc.
Perhaps the fix would be to pr
On Sep 03 12:37 Corinna Vinschen wrote:
> On Sep 2 23:32, John Carey wrote:
> > In Aug 17 10:15, Corinna Vinschen wrote:
> > > I just released 1.7.6-1.
> > ...
> > > What changed since Cygwin 1.7.5:
> > >
> > >
&
On Aug 12 01:11, Corinna Vinschen wrote:
> On Aug 12 06:54, Andy Koppe wrote:
> > On 11 August 2010 20:55, John Carey wrote:
> > > So is your idea that if SetCurrentDirectory() fails because
> > > of path length or permissions, then Cygwin would just accept
> > &
On Aug 11 01:49 Corinna Vinschen wrote:
> On Aug 10 21:53, John Carey wrote:
> > Now, where is Windows stuffing the extra copy of the directory handle?
> > In those reference-counted heap-allocated directory objects. Stepping
> > through the machine code under Windows 7 I se
On Aug 10 13:44 +0200 Corinna Vinschen wrote:
> > On Aug 10 00:19, John Carey wrote:
...
> > Presumably the issues mentioned in the source comment may
> > also occur, but what I have seen myself is a subsequent call to
> > SetCurrentDirectory() closing, not the curre
Greetings, John Carey!
> After a call to SetCurrentDirectory(), I have seen occasional (< 5%)
> failures of CreatePipe() with code ERROR_INVALID_HANDLE. I have also seen
> failure of Cygwin signal handling because the signal handling pipe has
> mysteriously closed.
Seems like it
After a call to SetCurrentDirectory(), I have seen occasional (< 5%) failures
of CreatePipe() with code ERROR_INVALID_HANDLE. I have also seen failure of
Cygwin signal handling because the signal handling pipe has mysteriously closed.
I believe that both symptoms are due to this code in winsup/
20 matches
Mail list logo
