RE: call_handler, interrupt_now and interruptible

RE: call_handler, interrupt_now and interruptible

[Fifer, Eric]

"Ray Easton" writes:
>> Anyways, is this dangerous to do?
>
>If 'this' means interrupting a DLL while it is "paused on a system
>call", yes, it is extermely dangerous and can leave the NT kernel in a
>corrupt state.  (This has nothing to do with Cygwin -- this is purely
>an NT issue.)

Actually, by 'this' I meant comment out 'pchigh == 0x60000000'.  And,
when I wrote 'system call' I meant a Cygwin system call like read, but
since most things are emulated on top of Win32 calls, eventually there
might be a Win32 call like ReadFile.  AFAICT, Cygwin signals are emulated
with Win32 threads and semaphores.  A Cygwin process has a "sig" thread
and a "main" thread, when a signal is sent, the "sig" thread receives it,
does a SuspendThread on the "main" thread and does a GetThreadContext,
if it is "interruptible" the context is changed and the signal handler
is pushed on the stack and the new context is set with SetThreadContext
then followed by a ResumeThread.  I can see how this could be dangerous
although I'm fairly ignorant of Win32, so I'm not sure exactly what you
can do that will leave the NT kernel in a corrupt state.

Since when running pure user code pchigh was equal to 60000000 and when
"paused on a system call" (eventually a Win32 call) pchigh was equal to
70000000, considering 60000000 as "interruptible" might be safe.

Of course, some real documentation about the contents of the Eip member
of the CONTENTS structure might help.

However, this leaves open the possibility that you might be in a Cygwin
system call (pchigh equal to 60000000?), but not in a Win32 call (pchigh
equal to 70000000?)  and interrupting the Cygwin DLL might be dangerous
to Cygwin.  I didn't test what the value of pchigh is when in a Cygwin
system call, but not a Win32 system call.  I guess I'm assuming in this
case, pchigh is equal to 60000000 and that you can't tell the difference
between being in the Cygwin DLL versus any other DLL :-(  Perhaps, Cygwin
needs a different mechanism for not interrupting the Cygwin DLL?

>>Is there a way to tell the difference between being in a normal DLL,
>>versus a "system" (what does this mean?) or cygwin DLL?
>
>Suppose there were (I don't think there is, and I don't think the notion
>of a "system" DLL even makes sense) -- how would you know that the
>"normal" DLL is not issuing a system call?  And if you can't know that,
>then you're in the case above.

Agreed.

Regards,

Eric Fifer

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: call_handler, interrupt_now and interruptible

[Chris Faylor]

On Thu, Feb 03, 2000 at 06:38:43PM -0000, Fifer, Eric wrote:
>
>"Ray Easton" writes:
>>> Anyways, is this dangerous to do?
>>
>>If 'this' means interrupting a DLL while it is "paused on a system
>>call", yes, it is extermely dangerous and can leave the NT kernel in a
>>corrupt state.  (This has nothing to do with Cygwin -- this is purely
>>an NT issue.)
>
>Actually, by 'this' I meant comment out 'pchigh == 0x60000000'.  And,
>when I wrote 'system call' I meant a Cygwin system call like read, but
>since most things are emulated on top of Win32 calls, eventually there
>might be a Win32 call like ReadFile.  AFAICT, Cygwin signals are emulated
>with Win32 threads and semaphores.  A Cygwin process has a "sig" thread
>and a "main" thread, when a signal is sent, the "sig" thread receives it,
>does a SuspendThread on the "main" thread and does a GetThreadContext,
>if it is "interruptible" the context is changed and the signal handler
>is pushed on the stack and the new context is set with SetThreadContext
>then followed by a ResumeThread.  I can see how this could be dangerous
>although I'm fairly ignorant of Win32, so I'm not sure exactly what you
>can do that will leave the NT kernel in a corrupt state.

The answer to your question is that this *is* dangerous to do.  It allows
cygwin "system calls" to be interrupted.

The code that you are investigating is essentially a stopgap until such
time as I have time to make it more foolproof.

As you've discovered, if you are using a snapshot, you're living on the
edge.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: call_handler, interrupt_now and interruptible

[Heribert Dahms]

Hi Chris,

you are are right, I said "I guess" and have not
actually seen any misbehavior. Indeed, I have a
single source file with a main() and no DLL of my
own at all. I'll test it as soon as I can find another
PC which I can unplug from network while running
without one of my collegues killing me...
Sorry for the false "alarm" 8-)

Bye, Heribert (heribert_dahms@icon-gmbh.de)

> -----Original Message-----
> From:	'Chris Faylor' [SMTP:cgf@cygnus.com]
> Sent:	Saturday, February 05, 2000 00:26
> To:	Heribert Dahms
> Cc:	Fifer, Eric; 'Ray Easton'; cygwin@sourceware.cygnus.com
> Subject:	Re: call_handler, interrupt_now and interruptible
> 
> On Fri, Feb 04, 2000 at 10:45:14PM +0100, Heribert Dahms wrote:
> >I guess this breaks now my code, which basically does a select()
> until
> >a socket becomes readable, starts a loop preparing a timeout with
> >alarm(60) for the following blocking fgets(), which is normally reset
> >using alarm(0) after each line, but is supposed to be interrupted in
> >case of a bad behaving client?
> 
> Why have you reached this conclusion?  Have you actually
> noticed this behavior?  The changes that I made should not
> have eliminated functionality in anything but DLLs and
> that is only temporary.
> 
> If this is just supposition, then try the cygwin DLL.  There
> is no need to speculate about things breaking if you haven't
> actually checked the code in question.
> 
> cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: call_handler, interrupt_now and interruptible

['Chris Faylor']

On Fri, Feb 04, 2000 at 10:45:14PM +0100, Heribert Dahms wrote:
>I guess this breaks now my code, which basically does a select() until
>a socket becomes readable, starts a loop preparing a timeout with
>alarm(60) for the following blocking fgets(), which is normally reset
>using alarm(0) after each line, but is supposed to be interrupted in
>case of a bad behaving client?

Why have you reached this conclusion?  Have you actually
noticed this behavior?  The changes that I made should not
have eliminated functionality in anything but DLLs and
that is only temporary.

If this is just supposition, then try the cygwin DLL.  There
is no need to speculate about things breaking if you haven't
actually checked the code in question.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: call_handler, interrupt_now and interruptible

[Heribert Dahms]

Hi Chris,

I guess this breaks now my code, which basically
does a select() until a socket becomes readable,
starts a loop preparing a timeout with alarm(60)
for the following blocking fgets(), which is normally
reset using alarm(0) after each line, but is supposed
to be interrupted in case of a bad behaving client?

Bye, Heribert (heribert_dahms@icon-gmbh.de)

> -----Original Message-----
> From:	Chris Faylor [SMTP:cgf@cygnus.com]
> Sent:	Friday, February 04, 2000 00:26
> To:	Fifer, Eric
> Cc:	'Ray Easton'; cygwin@sourceware.cygnus.com
> Subject:	Re: call_handler, interrupt_now and interruptible
> 
> On Thu, Feb 03, 2000 at 06:38:43PM -0000, Fifer, Eric wrote:
> >
> >"Ray Easton" writes:
> >>> Anyways, is this dangerous to do?
> >>
> >>If 'this' means interrupting a DLL while it is "paused on a system
> >>call", yes, it is extermely dangerous and can leave the NT kernel in
> a
> >>corrupt state.  (This has nothing to do with Cygwin -- this is
> purely
> >>an NT issue.)
> 
> [Heribert]  [snip]
> 
> The answer to your question is that this *is* dangerous to do.  It
> allows
> cygwin "system calls" to be interrupted.
> 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

call_handler, interrupt_now and interruptible

[Fifer, Eric]

Since I switched over from b20.1 to the development snapshots, I've noticed
a difference in the behavior of signal delivery.

Right now, I can't seem to immediately catch signals while calculations are
going on in a DLL.

This behavior seems to be controlled by call_handler() in exceptions.cc and
in
particular by interruptible():

interruptible (DWORD pc)
{
  DWORD pchigh = pc & 0xf0000000;
  return ((pc >= (DWORD) &__sigfirst) && (pc <= (DWORD) &__siglast)) ||
         !(pchigh == 0xb0000000 || pchigh == 0x70000000 || pchigh ==
0x60000000);
}

The comment in the ChangeLog when this was introduced is:

	Implement new signal-handling scheme which ensures that a program
will
	not be interrupted while in a system or cygwin DLL

Anyways, I added some more debugging to see the value of pc when sending
signals (I'm catching/sending SIGUSR1 in my experiments):

1) Running a busy loop in an EXE:

	pc=4010CD   pchigh=0        sigfirst=6A7CAF03 siglast=6A7CAF95

This is fine.

2) Running a busy loop in a DLL:

	pc=60C81059 pchigh=60000000 sigfirst=6A7CAF03 siglast=6A7CAF95

In this case the SIGUSR1 isn't processed until after the DLL returns.  So
I can't use signal handlers to peer into long running calculations that
happen to be done in a DLL.

3) When paused on a system call in a EXE or DLL:

	pc=77F6825B pchigh=70000000 sigfirst=6A7CAF03 siglast=6A7CAF95

I then experimented by commenting out "pchigh == 0x60000000", and things
work
more like I expect (and as they did under b20.1).  Of course, this goes
against
the intent of the comment.  Anyways, is this dangerous to do?  Is it an
appropriate
fix?  Where are the contents of cx->Eip described (I didn't find anything in
MSDN)?
Is there a way to tell the difference between being in a normal DLL, versus
a 
"system" (what does this mean?) or cygwin DLL?

Thanks in advance.

Eric Fifer

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com