RE: broken CTRL-BREAK handling

[Troy Noble <troy dot noble at channelpoint dot com>]

Christopher,

Let me first say something, then I'll respond to your comments
in your reply (and apologize as needed of course) and talk about
this new problem I mentioned a bit more.

I reluctantly withdraw my CTRL-BREAK suggestion.

Regarding the b20.1 and 1.x handling CTRL_BREAK the same way... confirmed.
I read through the b20.1 exceptions.cc last night and saw what you were
talking about.

I switched back to b20.1 and did some testing, and it turns out it didn't
handle CTRL-BREAK any differently, just as you'd expected.  What it did do
is intercept the press of the [X] button in the upper right corner
of the console window and JVM dumped a stack trace.  That must be the
incantation I was using with b20.1 + JVM.  Turns out that the
out-of-the-box version of Cygwin 1.3.2 does this too.  Can't
believe I missed that.

I want to go on record as saying that I'm still not convinced it's
entirely right for the ctrl handler to swallow the CTRL-BREAK and
turn it into a SIGINT in all cases.  Let me explain.  If I press
CTRL-BREAK in a cmd window JVM dumps stack traces, if I do the same
in bash/cygwin console window it doesn't.

Bottom line... that still feels broken to me if the intent is for
cygwin (more specifically, the bash shell running with cygwin) to
be able to launch/stop native win32 apps with the same semantics one
has come to expect when running cmd shell.
If that's not the goal, then it's a non-issue.

I have followed cygwin for quite some time, so I do understand
the issues related to cygwin being a *nix kernel/RTL emulation layer,
but it is also a win32 app in the sense that it still depends on the win32
API to some degree.  I am not sure to what extent you intend for it
to be a drop-in replacement for cmd.exe, or to play nicely with
other win32 native apps.  But this difference in CTRL_BREAK handling
is one sense it which it does not work the same way as cmd.exe.

Anyway, I don't want to get into design philosophy too deeply.
That's not my place to talk about such things.

Now to respond to your reply... (don't worry, I'm not
disposed to flaming).

> There is no more need to refresh my memory than there is to gratuitously
> mention that there are supposed bugs in 1.x versions of cygwin that
> aren't in B20.1.

> What information is conveyed by making assertions like this?  What was
> the intent beyond "yanking my chain"?

Sorry, it was not my intent at all to yank anyone's chain or to offend.
I would not bite the hand that feeds me so to speak.  I was just frustrated
with what I possibly misinterpreted as a "go away" response.  Sorry to
be reactive.  Maybe that's not what you were saying.

I know you get a lot of mail.  Probably more than you care to
read or possibly have time to read.  My intent was only to say that I
have been quite verbose and thorough in reporting the problems I've
found, and that I wasn't purposely trying to be vague in my other message...
just not wanting to rehash the whole 35 message thread of CTRL-C problems
all over again (for which everyone is most thankful I'm sure).  I'm sorry
for the wording and if it came across the wrong way.

What you are hearing coming through is my frustration at having spent
65+ hours trying to track down the CTRL-C thing and still not getting
it right.  I just ran out of time, and it bugs me that I had to leave
it unresolved to your satisfaction... so I went with the quicker fix
that solves our specific problem even though it's not 100% correct.
It's not frustration with you, as much as it is frustration with the
problem and my inability to reason my way through to a proper fix yet.

I understand and fully embrace the
notion of GPL, open source, and the roll-up-your-sleaves-
grab-a-bucket-and-start-bailing approach to solving problems.
Hopefully I've demonstrated that I'm not just whining, but am
willing to help.

> I understand that you have found what you consider to be bugs in the
> interaction of cygwin with non-cygwin processes and I have expressed my
> appreciation of the fact that you've submitted patches to attempt to
> work around the problems.  I can appreciate that it is discouraging to
> have your patches rejected but I'm sure you can appreciate my situation
> also.  I'm not going to accept changes which I think are incorrect.  I
> think I have explained why the patches are incorrect.

You have.  And I want to go on record as saying that I agree.
But you are right, I am disappointed... but not in you or your responses,
just that I've not solved it yet.

> I still intend to investigate the CTRL-C issues that you mentioned at
> some point.  It is on my list, if you don't come up with a patch.

Thanks, I don't mean to sound ungrateful in any way.  I am quite thankful
for any help you can provide on this one, as I haven't had time to get
back to it to solve it the right way yet.  And frankly, the intricacies
of some of the code elude me with my current understanding... until I
get time to crawl in deeper and learn more about the internals.  But that's
no fault of yours.  There's just not enough time in my day right now.
That's not an excuse, just stating the facts.  I will get back to it
someday.  I'm not sloughing off and waiting for you to fix it for me in
other words.

>Here's the things I've reported thusfar:
>
>1. CTRL-C handling is broken with CYGWIN=notty in an emacs buffer.
>   I submitted patches for this already, in 5 different forms, each
>   of which fixed the problem in a different way.  I never did hit
>   on the right combination that you were looking for, and my
>   patches were rejected.  I gave up and patched my own copy from
>   the sources, and it's been working nicely for me for 2 months now.
>   All the other emacs users are still stuck though I suspect.
>2. CTRL-BREAK handling is broken, which I just reported and
>   mentioned a fix.  I patched my own copy of the DLL with this
>   as well, and it now behaves just like it did back in b20.1.
>
>The third, which I've not reported yet...

> Ok, so, your "several" bugs is actually one previously reported problem,
> one arguable bug reported today, and one problem that has, to the best
> of my knowledge, never been reported by anyone else.

As I said it's hard to reproduce, and only happens under heavy load.  I
have been following this for several months now (since I first tried
1.8.1-1) and have seen at least a couple of other posts related to
bad interactions with winamp and cygwin.  Since it is hard to reproduce,
that's why I don't have more data yet.  For which I'm truly sorry.
I will keep at it.  I am convinced it is a real problem at this point
That was a real stack trace I sent, and is indicative of the failure
mode I see when I can reproduce it.

Here's one of the posts.

http://sources.redhat.com/ml/cygwin/2001-05/msg00518.html

IIRC someone simply suggested he not run winamp and cygwin at the same time.
My hypothesis is that it has to do with frequent process switching and
a race condition in cygheap.  If the cygwin process gets switched out
such that heap initialization gets interrupted midstream and it doesn't
complete "fast enough", the cygwin1.dll produces an Access Violation.
If I can figure out what "fast enough" means I can hopefully find
the solution.  Maybe adding some sleep() calls in cygheap might show
me.  Hmm... haven't tried that yet.

> >At least my problems are getting fixed, but I'm having to do it
> >all myself.  It's just unfortunate nobody else has gotten to take
> >advantage of any fixes I've submitted yet.
> 
> Are you saying that I approved one of your patches and it hasn't been
> applied?  I don't recall doing that.  If I have approved a patch and
> have not applied it, then I apologize.  If you can point me to the URL
> that contains the approval, I'll apply the patch.

Sorry, I miscommunicated again.  What I meant was that at least at this
point I've fixed the couple of problems I was seeing and recompiled a DLL
that
temporarily works around my specific problems.  You haven't forgotten to
apply
any patches that you've accepted from me, because you haven't accepted any
yet.  Again, I understand your reasoning completely.  It's just back to the
drawing board for me as time permits.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/