> 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]
> > > > S
ely 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 1.7.9, so in that sense
od.
> > >
> > > 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 change.
>
> I add
> 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 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 other Win32 API functions. (It may
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 since
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 a
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 think.
First of all, I'm
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 be some kind of rule
to pick
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/problems.html
FAQ
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.
...
What changed since Cygwin 1.7.5
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.
It looks to me as if the MOUNT_SYSTEM bit is copied from
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:
- Cygwin handles the current working directory entirely on its own
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
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
the failure and keep an internal record
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 see SetCurrentDirectory
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 was discussed a short
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 current directory handle, but
the handle
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
20 matches
Mail list logo
