39d0171500
* cygtls.h (_cygtls::push): Inline. (_cygtls::interrupt_now): Change signal number argument to siginfo_t argument. (_cygtls::interrupt_setup): Ditto. (_cygtls::set_siginfo): Delete declaration. (_cygtls::reset_signal_arrived): Don't reset signal_arrived signal. Just reset flag. * exceptions.cc (_cygtls::interrupt_now): Reflect argument changes. Pass si to interrupt_setup. (_cygtls::interrupt_setup): Reflect argument changes. Fill out tls infodata here using passed-in si. Use si.si_signo instead of sig. (sigpacket::setup_handler): Move this function into sigpacket class. Use si field from the class as appropriate. (sigpacket::process): Don't call tls->set_siginfo here since setup_handler could fail. Eliminate now-unneeded sig argument. * sigproc.h (sigpacket::setup_handler): Move setup_handler to this class.
416 lines
18 KiB
Plaintext
416 lines
18 KiB
Plaintext
2012-08-17 cgf-000016
|
|
|
|
While debugging another problem I finally noticed that
|
|
sigpacket::process was unconditionally calling tls->set_siginfo prior to
|
|
calling setup_handler even though setup_handler could fail. In the
|
|
event of two successive signals, that would cause the second signal's
|
|
info to overwrite the first even though the signal handler for the first
|
|
would eventually be called. Doh.
|
|
|
|
Fixing this required passing the sigpacket si field into setup_handler.
|
|
Making setup_handler part of the sigpacket class seemed to make a lot of
|
|
sense so that's what I did. Then I passed the si element into
|
|
interrupt_setup so that the infodata structure could be filled out prior
|
|
to arming the signal.
|
|
|
|
The other changes checked in here eliminate the ResetEvent for
|
|
signal_arrived since previous changes to cygwait should handle the
|
|
case of spurious signal_arrived detection. Since signal_arrived is
|
|
not a manual-reset event, we really should just let the appropriate
|
|
WFMO handle it. Otherwise, there is a race where a signal comes in
|
|
a "split second" after WFMO responds to some other event. Resetting
|
|
the signal_arrived would cause any subsequent WFMO to never be
|
|
triggered. My current theory is that this is what is causing:
|
|
|
|
http://cygwin.com/ml/cygwin/2012-08/msg00310.html
|
|
|
|
2012-08-15 cgf-000015
|
|
|
|
RIP cancelable_wait. Yay.
|
|
|
|
2012-08-09 cgf-000014
|
|
|
|
So, apparently I got it somewhat right before wrt signal handling.
|
|
Checking on linux, it appears that signals will be sent to a thread
|
|
which can accept the signal. So resurrecting and extending the
|
|
"find_tls" function is in order. This function will return the tls
|
|
of any thread which 1) is waiting for a signal with sigwait*() or
|
|
2) has the signal unmasked.
|
|
|
|
In redoing this it became obvious that I had the class designation wrong
|
|
for the threadlist handling so I moved the manipulation of the global
|
|
threadlist into the cygheap where it logically belongs.
|
|
|
|
2012-07-21 cgf-000013
|
|
|
|
These changes reflect a revamp of the "wait for signal" functionality
|
|
which has existed in Cygwin through several signal massages.
|
|
|
|
We now create a signal event only when a thread is waiting for a signal
|
|
and arm it only for that thread. The "set_signal_arrived" function is
|
|
used to establish the event and set it in a location referencable by
|
|
the caller.
|
|
|
|
I still do not handle all of the race conditions. What happens when
|
|
a signal comes in just after a WF?O succeeds for some other purpose? I
|
|
suspect that it will arm the next WF?O call and the subsequent call to
|
|
call_signal_handler could cause a function to get an EINTR when possibly
|
|
it shouldn't have.
|
|
|
|
I haven't yet checked all of the test cases for the URL listed in the
|
|
previous entry.
|
|
|
|
Baby steps.
|
|
|
|
2012-06-12 cgf-000012
|
|
|
|
These changes are the preliminary for redoing the way threads wait for
|
|
signals. The problems are shown by the test case mentioned here:
|
|
|
|
http://cygwin.com/ml/cygwin/2012-05/msg00434.html
|
|
|
|
I've known that the signal handling in threads wasn't quite right for
|
|
some time. I lost all of my thread signal tests in the great "rm -r"
|
|
debacle of a few years ago and have been less than enthusiastic about
|
|
redoing everything (I had PCTS tests and everything). But it really is
|
|
time to redo this signal handling to make it more like it is supposed to
|
|
be.
|
|
|
|
This change should not introduce any new behavior. Things should
|
|
continue to behave as before. The major differences are a change in the
|
|
arguments to cancelable_wait and cygwait now uses cancelable_wait and,
|
|
so, the returns from cygwait now mirror cancelable_wait.
|
|
|
|
The next change will consolidate cygwait and cancelable_wait into one
|
|
cygwait function.
|
|
|
|
2012-06-02 cgf-000011
|
|
|
|
The refcnt handling was tricky to get right but I had convinced myself
|
|
that the refcnt's were always incremented/decremented under a lock.
|
|
Corinna's 2012-05-23 change to refcnt exposed a potential problem with
|
|
dup handling where the fdtab could be updated while not locked.
|
|
|
|
That should be fixed by this change but, on closer examination, it seems
|
|
like there are many places where it is possible for the refcnt to be
|
|
updated while the fdtab is not locked since the default for
|
|
cygheap_fdget is to not lock the fdtab (and that should be the default -
|
|
you can't have read holding a lock).
|
|
|
|
Since refcnt was only ever called with 1 or -1, I broke it up into two
|
|
functions but kept the Interlocked* operation. Incrementing a variable
|
|
should not be as racy as adding an arbitrary number to it but we have
|
|
InterlockedIncrement/InterlockedDecrement for a reason so I kept the
|
|
Interlocked operation here.
|
|
|
|
In the meantime, I'll be mulling over whether the refcnt operations are
|
|
actually safe as they are. Maybe just ensuring that they are atomically
|
|
updated is enough since they control the destruction of an fh. If I got
|
|
the ordering right with incrementing and decrementing then that should
|
|
be adequate.
|
|
|
|
2012-06-02 cgf-000010
|
|
|
|
<1.7.16>
|
|
- Fix emacs problem which exposed an issue with Cygwin's select() function.
|
|
If a signal arrives while select is blocking and the program longjmps
|
|
out of the signal handler then threads and memory may be left hanging.
|
|
Fixes: http://cygwin.com/ml/cygwin/2012-05/threads.html#00275
|
|
</1.7.16>
|
|
|
|
This was try #4 or #5 to get select() signal handling working right.
|
|
It's still not there but it should now at least not leak memory or
|
|
threads.
|
|
|
|
I mucked with the interface between cygwin_select and select_stuff::wait
|
|
so that the "new" loop in select_stuff::wait() was essentially moved
|
|
into the caller. cygwin_select now uses various enum states to decide
|
|
what to do. It builds the select linked list at the beginning of the
|
|
loop, allowing wait() to tear everything down and restart. This is
|
|
necessary before calling a signal handler because the signal handler may
|
|
longjmp away.
|
|
|
|
I initially had this all coded up to use a special signal_cleanup
|
|
callback which could be called when a longjmp is called in a signal
|
|
handler. And cygwin_select() set up and tore down this callback. Once
|
|
I got everything compiling it, of course, dawned on me that just because
|
|
you call a longjmp in a signal handler it doesn't mean that you are
|
|
jumping *out* of the signal handler. So, if the signal handler invokes
|
|
the callback and returns it will be very bad for select(). Hence, this
|
|
slower, but hopefully more correct implementation.
|
|
|
|
(I still wonder if some sort of signal cleanup callback might still
|
|
be useful in the future)
|
|
|
|
TODO: I need to do an audit of other places where this problem could be
|
|
occurring.
|
|
|
|
As alluded to above, select's signal handling is still not right. It
|
|
still acts as if it could call a signal handler from something other
|
|
than the main thread but, AFAICT, from my STC, this doesn't seem to be
|
|
the case. It might be worthwhile to extend cygwait to just magically
|
|
figure this out and not even bother using w4[0] for scenarios like this.
|
|
|
|
2012-05-16 cgf-000009
|
|
|
|
<1.7.16>
|
|
- Fix broken console mouse handling. Reported here:
|
|
http://cygwin.com/ml/cygwin/2012-05/msg00360.html
|
|
</1.7.16>
|
|
|
|
I did a cvs annotate on smallprint.cc and see that the code to translate
|
|
%characters > 127 to 0x notation was in the 1.1 revision. Then I
|
|
checked the smallprint.c predecessor. It was in the 1.1 version of that
|
|
program too, which means that this odd change has probably been around
|
|
since <= 2000.
|
|
|
|
Since __small_sprintf is supposed to emulate sprintf, I got rid of the
|
|
special case handling. This may affect fhandler_socket::bind. If so, we
|
|
should work around this problem there rather than keeping this strange
|
|
hack in __small_printf.
|
|
|
|
2012-05-14 cgf-000008
|
|
|
|
<1.7.16>
|
|
- Fix hang when zero bytes are written to a pty using
|
|
Windows WriteFile or equivalent. Fixes:
|
|
http://cygwin.com/ml/cygwin/2012-05/msg00323.html
|
|
</1.7.16>
|
|
|
|
cgf-000002, as usual, fixed one thing while breaking another. See
|
|
Larry's predicament in: http://goo.gl/oGEr2 .
|
|
|
|
The problem is that zero byte writes to the pty pipe caused the dread
|
|
end-of-the-world-as-we-know-it problem reported on the mailing list
|
|
where ReadFile reads zero bytes even though there is still more to read
|
|
on the pipe. This is because that change caused a 'record' to be read
|
|
and a record can be zero bytes.
|
|
|
|
I was never really keen about using a throwaway buffer just to get a
|
|
count of the number of characters available to be read in the pty pipe.
|
|
On closer reading of the documentation for PeekNamedPipe it seemed like
|
|
the sixth argument to PeekNamedPipe should return what I needed without
|
|
using a buffer. And, amazingly, it did, except that the problem still
|
|
remained - a zero byte message still screwed things up.
|
|
|
|
So, we now detect the case where there is zero bytes available as a
|
|
message but there are bytes available in the pipe. In that scenario,
|
|
return the bytes available in the pipe rather than the message length of
|
|
zero. This could conceivably cause problems with pty pipe handling in
|
|
this scenario but since the only way this scenario could possibly happen
|
|
is when someone is writing zero bytes using WriteFile to a pty pipe, I'm
|
|
ok with that.
|
|
|
|
2012-05-14 cgf-000007
|
|
|
|
<1.7.16>
|
|
- Fix invocation of strace from a cygwin process. Fixes:
|
|
http://cygwin.com/ml/cygwin/2012-05/msg00292.html
|
|
</1.7.16>
|
|
|
|
The change in cgf-000004 introduced a problem for processes which load
|
|
cygwin1.dll dynamically. strace.exe is the most prominent example of
|
|
this.
|
|
|
|
Since the parent handle is now closed for "non-Cygwin" processes, when
|
|
strace.exe tried to dynamically load cygwin1.dll, the handle was invalid
|
|
and child_info_spawn::handle_spawn couldn't use retrieve information
|
|
from the parent. This eventually led to a strace_printf error due to an
|
|
attempt to dereference an unavailable cygheap. Probably have to fix
|
|
this someday. You shouldn't use the cygheap while attempting to print
|
|
an error about the inavailability of said cygheap.
|
|
|
|
This was fixed by saving the parent pid in child_info_spawn and calling
|
|
OpenProcess for the parent pid and using that handle iff a process is
|
|
dynamically loaded.
|
|
|
|
2012-05-12 cgf-000006
|
|
|
|
<1.7.16>
|
|
- Fix hang when calling pthread_testcancel in a canceled thread.
|
|
Fixes some of: http://cygwin.com/ml/cygwin/2012-05/msg00186.html
|
|
</1.7.16>
|
|
|
|
This should fix the first part of the reported problem in the above
|
|
message. The cancel seemed to actually be working but, the fprintf
|
|
eventually ended up calling pthread_testcancel. Since we'd gotten here
|
|
via a cancel, it tried to recursively call the cancel handler causing a
|
|
recursive loop.
|
|
|
|
2012-05-12 cgf-000005
|
|
|
|
<1.7.16>
|
|
- Fix pipe creation problem which manifested as a problem creating a
|
|
fifo. Fixes: http://cygwin.com/ml/cygwin/2012-05/msg00253.html
|
|
</1.7.16>
|
|
|
|
My change on 2012-04-28 introduced a problem with fifos. The passed
|
|
in name was overwritten. This was because I wasn't properly keeping
|
|
track of the length of the generated pipe name when there was a
|
|
name passed in to fhandler_pipe::create.
|
|
|
|
There was also another problem in fhandler_pipe::create. Since fifos
|
|
use PIPE_ACCESS_DUPLEX and PIPE_ACCESS_DUPLEX is an or'ing of
|
|
PIPE_ACCESS_INBOUND and PIPE_ACCESS_OUTBOUND, using PIPE_ACCESS_OUTBOUND
|
|
as a "never-used" option for PIPE_ADD_PID in fhandler.h was wrong. So,
|
|
fifo creation attempted to add the pid of a pipe to the name which is
|
|
wrong for fifos.
|
|
|
|
2012-05-08 cgf-000004
|
|
|
|
The change for cgf-000003 introduced a new problem:
|
|
http://cygwin.com/ml/cygwin/2012-05/msg00154.html
|
|
http://cygwin.com/ml/cygwin/2012-05/msg00157.html
|
|
|
|
Since a handle associated with the parent is no longer being duplicated
|
|
into a non-cygwin "execed child", Windows is free to reuse the pid of
|
|
the parent when the parent exits. However, since we *did* duplicate a
|
|
handle pointing to the pid's shared memory area into the "execed child",
|
|
the shared memory for the pid was still active.
|
|
|
|
Since the shared memory was still available, if a new process reuses the
|
|
previous pid, Cygwin would detect that the shared memory was not created
|
|
and had a "PID_REAPED" flag. That was considered an error, and, so, it
|
|
would set procinfo to NULL and pinfo::thisproc would die since this
|
|
situation is not supposed to occur.
|
|
|
|
I fixed this in two ways:
|
|
|
|
1) If a shared memory region has a PID_REAPED flag then zero it and
|
|
reuse it. This should be safe since you are not really supposed to be
|
|
querying the shared memory region for anything after PID_REAPED has been
|
|
set.
|
|
|
|
2) Forego duping a copy of myself_pinfo if we're starting a non-cygwin
|
|
child for exec.
|
|
|
|
It seems like 2) is a common theme and an audit of all of the handles
|
|
that are being passed to non-cygwin children is in order for 1.7.16.
|
|
|
|
The other minor modification that was made in this change was to add the
|
|
pid of the failing process to fork error output. This helps slightly
|
|
when looking at strace output, even though in this case it was easy to
|
|
find what was failing by looking for '^---' when running the "stv"
|
|
strace dumper. That found the offending exception quickly.
|
|
|
|
2012-05-07 cgf-000003
|
|
|
|
<1.7.15>
|
|
Don't make Cygwin wait for all children of a non-cygwin child program.
|
|
Fixes: http://cygwin.com/ml/cygwin/2012-05/msg00063.html,
|
|
http://cygwin.com/ml/cygwin/2012-05/msg00075.html
|
|
</1.7.15>
|
|
|
|
This problem is due to a recent change which added some robustness and
|
|
speed to Cygwin's exec/spawn handling by not trying to force inheritance
|
|
every time a process is started. See ChangeLog entries starting on
|
|
2012-03-20, and multiple on 2012-03-21.
|
|
|
|
Making the handle inheritable meant that, as usual, there were problems
|
|
with non-Cygwin processes. When Cygwin "execs" a non-Cygwin process N,
|
|
all of its N + 1, N + 2, ... children will also inherit the handle.
|
|
That means that Cygwin will wait until all subprocesses have exited
|
|
before it returns.
|
|
|
|
I was willing to make this a restriction of starting non-Cygwin
|
|
processes but the problem with allowing that is that it can cause the
|
|
creation of a "limbo" pid when N exits and N + 1 and friends are still
|
|
around. In this scenario, Cygwin dutifully notices that process N has
|
|
died and sets the exit code to indicate that but N's parent will wait on
|
|
rd_proc_pipe and will only return when every N + ... windows process
|
|
has exited.
|
|
|
|
The removal of cygheap::pid_handle was not related to the initial
|
|
problem that I set out to fix. The change came from the realization
|
|
that we were duping the current process handle into the child twice and
|
|
only needed to do it once. The current process handle is used by exec
|
|
to keep the Windows pid "alive" so that it will not be reused. So, now
|
|
we just close parent in child_info_spawn::handle_spawn iff we're not
|
|
execing.
|
|
|
|
In debugging this it bothered me that 'ps' identified a nonactive pid as
|
|
active. Part of the reason for this was the 'parent' handle in
|
|
child_info was opened in non-Cygwin processes, keeping the pid alive.
|
|
That has been kluged around (more changes after 1.7.15) but that didn't
|
|
fix the problem. On further investigation, this seems to be caused by
|
|
the fact that the shared memory region pid handles were still being
|
|
passed to non-cygwin children, keeping the pid alive in a limbo-like
|
|
fashion. This was easily fixed by having pinfo::init() consider a
|
|
memory region with PID_REAPED as not available. A more robust fix
|
|
should be considered for 1.7.15+ where these handles are not passed
|
|
to non-cygwin processes.
|
|
|
|
This fixed the problem where a pid showed up in the list after a user
|
|
does something like: "bash$ cmd /c start notepad" but, for some reason,
|
|
it does not fix the problem where "bash$ setsid cmd /c start notepad".
|
|
That bears investigation after 1.7.15 is released but it is not a
|
|
regression and so is not a blocker for the release.
|
|
|
|
2012-05-03 cgf-000002
|
|
|
|
<1.7.15>
|
|
Fix problem where too much input was attempted to be read from a
|
|
pty slave. Fixes: http://cygwin.com/ml/cygwin/2012-05/msg00049.html
|
|
</1.7.15>
|
|
|
|
My change on 2012/04/05 reintroduced the problem first described by:
|
|
http://cygwin.com/ml/cygwin/2011-10/threads.html#00445
|
|
|
|
The problem then was, IIRC, due to the fact that bytes sent to the pty
|
|
pipe were not written as records. Changing pipe to PIPE_TYPE_MESSAGE in
|
|
pipe.cc fixed the problem since writing lines to one side of the pipe
|
|
caused exactly that the number of characters to be read on the other
|
|
even if there were more characters in the pipe.
|
|
|
|
To debug this, I first replaced fhandler_tty.cc with the 1.258,
|
|
2012/04/05 version. The test case started working when I did that.
|
|
|
|
So, then, I replaced individual functions, one at a time, in
|
|
fhandler_tty.cc with their previous versions. I'd expected this to be a
|
|
problem with fhandler_pty_master::process_slave_output since that had
|
|
seen the most changes but was surprised to see that the culprit was
|
|
fhandler_pty_slave::read().
|
|
|
|
The reason was that I really needed the bytes_available() function to
|
|
return the number of bytes which would be read in the next operation
|
|
rather than the number of bytes available in the pipe. That's because
|
|
there may be a number of lines available to be read but the number of
|
|
bytes which will be read by ReadFile should reflect the mode of the pty
|
|
and, if there is a line to read, only the number of bytes in the line
|
|
should be seen as available for the next read.
|
|
|
|
Having bytes_available() return the number of bytes which would be read
|
|
seemed to fix the problem but it could subtly change the behavior of
|
|
other callers of this function. However, I actually think this is
|
|
probably a good thing since they probably should have been seeing the
|
|
line behavior.
|
|
|
|
2012-05-02 cgf-000001
|
|
|
|
<1.7.15>
|
|
Fix problem setting parent pid to 1 when process with children execs
|
|
itself. Fixes: http://cygwin.com/ml/cygwin/2012-05/msg00009.html
|
|
</1.7.15>
|
|
|
|
Investigating this problem with strace showed that ssh-agent was
|
|
checking the parent pid and getting a 1 when it shouldn't have. Other
|
|
stuff looked ok so I chose to consider this a smoking gun.
|
|
|
|
Going back to the version that the OP said did not have the problem, I
|
|
worked forward until I found where the problem first occurred -
|
|
somewhere around 2012-03-19. And, indeed, the getppid call returned the
|
|
correct value in the working version. That means that this stopped
|
|
working when I redid the way the process pipe was inherited around
|
|
this time period.
|
|
|
|
It isn't clear why (and I suspect I may have to debug this further at
|
|
some point) this hasn't always been a problem but I made the obvious fix.
|
|
We shouldn't have been setting ppid = 1 when we're about to pass off to
|
|
an execed process.
|
|
|
|
As I was writing this, I realized that it was necessary to add some
|
|
additional checks. Just checking for "have_execed" isn't enough. If
|
|
we've execed a non-cygwin process then it won't know how to deal with
|
|
any inherited children. So, always set ppid = 1 if we've execed a
|
|
non-cygwin process.
|