RE: broken CTRL-BREAK handling

RE: broken CTRL-BREAK handling

[Troy Noble]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6557 bytes --]

> Hmm.  I'll have to investigate this next week.  I can't easily retrieve
> the B20 sources right now.

I have the sources for b20.1 at my disposal too.  I will go look as
well. Just for grins.

> I think I recall that back in B20.1 days, people routinely
> provided details rather than make vague assertions, too.

Hmm... I have done that.  I know you get a lot of mail traffic, so
I'll refresh your memory.

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 because I don't have enough
details gathered yet is:

3. Access Violation.
   There appears to be a race condition in the cygwin heap initialization
   after a spawn.  It's almost like the "cygheap_protect->acquire ();"
   isn't doing the right thing.  But I've not nailed it down yet.
   Here's the backtrace:


(gdb) p buckets
$10 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x1a021ac4 "\005",
  0x6 <Address 0x6 out of bounds>, 0x1a028bfc "$\211\002\032'\213\002\032i",
  0x1a02825c "\204|\002\032O\201\002\032i",
  0x1a0289ac "?\205\002\032$\211\002\032i",
  0x1a02726c "ñd\002\032Dr\002\032i", 0x1a0212bc "\013",
  0x0 <repeats 20 times>}(gdb) p rvc
$7 = (_cmalloc_entry *) 0x6

(gdb) bt
#0  _cmalloc (size=6) at /work/build/src/winsup/cygwin/cygheap.cc:102
#1  0x61001c48 in cmalloc (x=HEAP_1_ARGV, n=24)
    at /work/build/src/winsup/cygwin/cygheap.cc:223
#2  0x61051f7b in spawn_guts (hToken=0x0,
    prog_arg=0x241f844 "/p4d/Build_win32_2.0/x86/cygwin/bin/md5sum",
    argv=0xa013740, envp=0xa010008, mode=3)
    at /work/build/src/winsup/cygwin/spawn.cc:230
#3  0x61053bbe in _spawnve (hToken=0x0, mode=3,
    path=0x241f844 "/p4d/Build_win32_2.0/x86/cygwin/bin/md5sum",
    argv=0xa013740, envp=0xa010008)
    at /work/build/src/winsup/cygwin/spawn.cc:881
#4  0x61010ab1 in _execve (
    path=0x241f844 "/p4d/Build_win32_2.0/x86/cygwin/bin/md5sum",
    argv=0xa013740, envp=0xa010008) at
/work/build/src/winsup/cygwin/exec.cc:35
#5  0x61010b2e in execv (
    path=0x241f844 "/p4d/Build_win32_2.0/x86/cygwin/bin/md5sum",
    argv=0xa013740) at /work/build/src/winsup/cygwin/exec.cc:62
#6  0x6107afb0 in execvp (file=0x1a023714 "md5sum", argv=0xa013740)
    at /work/build/src/newlib/libc/posix/execvp.c:81
#7  0x4056af in _size_of_heap_reserve__ ()
#8  0x4044eb in _size_of_heap_reserve__ ()
#9  0x404124 in _size_of_heap_reserve__ ()
#10 0x40151c in _size_of_heap_reserve__ ()
---Type <return> to continue, or q <return> to quit---
#11 0x401862 in _size_of_heap_reserve__ ()
#12 0x401673 in _size_of_heap_reserve__ ()
#13 0x401432 in _size_of_heap_reserve__ ()
#14 0x40134c in _size_of_heap_reserve__ ()
#15 0x61003fb4 in dll_crt0_1 () at
/work/build/src/winsup/cygwin/dcrt0.cc:862
#16 0x610042a5 in _dll_crt0 () at /work/build/src/winsup/cygwin/dcrt0.cc:928
#17 0x610042f1 in dll_crt0 (uptr=0x40f1d0)
    at /work/build/src/winsup/cygwin/dcrt0.cc:940
#18 0x40d28a in _size_of_heap_reserve__ ()
#19 0x401038 in _size_of_heap_reserve__ ()
#20 0x77f1b9ea in ?? ()


98        cygheap_protect->acquire ();
99        if (buckets[b])
100         {
101           rvc = (_cmalloc_entry *) buckets[b];
102           buckets[b] = rvc->ptr;
103           rvc->b = b;
104         }
105       else
106         {
107           size = sz + sizeof (_cmalloc_entry);
108           rvc = (_cmalloc_entry *) _csbrk (size);
109
110           rvc->b = b;
111           rvc->prev = cygheap->chain;
112           cygheap->chain = rvc;
113         }
114       cygheap_protect->release ();



It is particularly sensitive when running with cygwin and programs
like winamp where frequent process switching is happening, or under
heavy CPU load.  It is somewhat hard to reproduce, because you have
to load the machine down and then start/stop a whole bunch of
cygwin processes (like a make on a big source code tree which churns
through repeated invocations os make.exe, sh.exe, etc. at a fairly
good clip).

And you can't reproduce it when strace is running.  The I/O is enough
to slow things down to the point that it doesn't fail.

Once I get more details, I'll report this one too ;->

If I was just one of the yay-sayers saying "it's broke" or "me too",
I suppose I'd say I deserved that response.  The fact is that
I have taken the initiative to attempt to climb in and understand the
code and pitch in by running debugger sessions, finding work arounds,
submitting patches, etc.  From reading the web site, I think I've
tried to follow the recommended approach for getting things fixed...
ask for help, when we tell you to go away, go try to fix it yourself,
and send the patches to the list.

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.

Troy


-----Original Message-----
From: Christopher Faylor [ mailto:cgf@redhat.com ]
Sent: Tuesday, July 17, 2001 2:15 PM
To: cygwin@cygwin.com
Subject: Re: broken CTRL-BREAK handling


On Tue, Jul 17, 2001 at 02:06:21PM -0600, Troy Noble wrote:
>b20.1 handled it differently.  If I press the [X] or
>CTRL-BREAK in a b20.1 window, JDK dutifully dumps the
>stack trace.

Hmm.  I'll have to investigate this next week.  I can't easily retrieve
the B20 sources right now.

>Just one of several things that worked in b20.1 that are
>broken in cygwin 1.x.

I think I recall that back in B20.1 days, people routinely
provided details rather than make vague assertions, too.

Ah, those were the days.  Everything was so very much better.

cgf

--
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/

--
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/

Re: broken CTRL-BREAK handling

[Christopher Faylor]

On Tue, Jul 17, 2001 at 02:50:42PM -0600, Troy Noble wrote:
>> Hmm.  I'll have to investigate this next week.  I can't easily retrieve
>> the B20 sources right now.
>
>I have the sources for b20.1 at my disposal too.  I will go look as
>well. Just for grins.
>
>> I think I recall that back in B20.1 days, people routinely
>> provided details rather than make vague assertions, too.
>
>Hmm... I have done that.  I know you get a lot of mail traffic, so
>I'll refresh your memory.

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"?

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.

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.

>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.

>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.

cgf

--
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/

RE: broken CTRL-BREAK handling

[Karr, David]

I've seen several discussions over the last few months which essentially
boil down to some people wanting convenience vs. other people wanting
"clarity of purpose", for lack of a better term.  I'm very sympathetic to
Unix users wanting their "ported-to-cygwin" apps to work as similarly as
possible on Cygwin.  I worked on Unix for many years before working the last
few in a "mixed" environment.

Frankly, I think the best approach is to consider a "pragmatic" approach.  I
wouldn't want to do anything to prevent Unix applications from working
without change, but I also think it's odd to try to "hide" from the fact
that you're running on Windows.  It seems perfectly reasonable (and
convenient) to have "pragmatic" features in Cygwin, which accepts the fact
that we're in a Windows environment.  I think this issue probably falls into
that area, and others like understanding "c:/filepath" also.

I'm not as informed on these issues as I'd like, but this is just my
impression from my experience.

-----Original Message-----
From: Michael A. Chase [ mailto:mchase@ix.netcom.com ]
Sent: Wednesday, July 18, 2001 4:27 PM
To: Troy Noble; cygwin@cygwin.com
Subject: Re: broken CTRL-BREAK handling


----- Original Message -----
From: "Troy Noble" <troy.noble@channelpoint.com>
To: <cygwin@cygwin.com>
Sent: Wednesday, July 18, 2001 09:32
Subject: RE: broken CTRL-BREAK handling


> 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.

My understanding is just about the opposite.  The purpose of Cygwin is to
allow UNIX applications to build and run under Win32 with as few changes as
possible.  That you can run Win32 apps from bash as well is just an extra
benefit.



--
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/

--
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/

Re: broken CTRL-BREAK handling

[Michael A. Chase]

----- Original Message -----
From: "Troy Noble" <troy.noble@channelpoint.com>
To: <cygwin@cygwin.com>
Sent: Wednesday, July 18, 2001 09:32
Subject: RE: broken CTRL-BREAK handling


> 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.

My understanding is just about the opposite.  The purpose of Cygwin is to
allow UNIX applications to build and run under Win32 with as few changes as
possible.  That you can run Win32 apps from bash as well is just an extra
benefit.



--
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/

RE: broken CTRL-BREAK handling

[Troy Noble]

A good suggestion.

Under Linux or Solaris, the standard way of forcing Sun's JVM to dump the
current thread stacks is

$ kill -SIGQUIT <pid-of-your-jvm>

or equivalently:

$ kill -3 <pid-of-your-jvm>

On AIX, with IBM's JVM you can use -SIGUSR1.
Not sure of other JVM ports, but that's how the two JVMs
I've used do it.

Unfortunately, the win32 version of Sun's JVM is a
native Win32 app, and doesn't handle signals in *nix fashion...
since it's only got the Win32 API at its disposal.  All the
signal handling that cygwin uses/provides is implemented as part of
cygwin in other words.
Sun's JVM registers a console ctrl handler, which when invoked
with type==CTRL_BREAK_EVENT dumps the thread stacks.  The
interaction with cygwin is that when I start JVM from cygwin's
bash, a CTRL-BREAK results in a kill of all of the processes in
the process group (including my JVM process) before the JVM's
control handler gets called.  Thus the root of my particular
problem, which I was trying to work around.

I [re]discovered that can press the close button ([X]) at the
upper right corner of the bash console window to produce the
stack trace.  Not as pretty, and doesn't work in Emacs (C-c C-\),
but it's a work around nonetheless.

Now, if I could get Sun to port their JVM over to cygwin,
and then setup a proper POSIX-style signal handler
such as cygwin provides (which win32 doesn't)... but
then I wake up and realize I'm daydreaming again.

Thanks for the suggestion.  It was definitely worth a shot.

Troy

-----Original Message-----
From: Heribert Dahms [ mailto:heribert_dahms@icon-scm.com ]
Sent: Wednesday, July 18, 2001 2:42 PM
To: 'Troy Noble'; 'cygwin@cygwin.com'
Subject: RE: broken CTRL-BREAK handling


Hi Troy,

for the unix-emulation-centered like me it's a non issue
and I'd turn the question into:
Is there a (standard) way of generating a JVM dump under Unix?
If so, you may try that under Cygwin.

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

> -----Original Message-----
> From:	Troy Noble [SMTP:troy.noble@channelpoint.com]
> Sent:	Wednesday, July 18, 2001 18:33
> To:	'cygwin@cygwin.com'
> Subject:	RE: broken CTRL-BREAK handling
> 
	[Heribert]  [snip]

> 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.
> 
	[Heribert]  [snip]
>  

--
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/

RE: broken CTRL-BREAK handling

[Heribert Dahms]

Hi Troy,

for the unix-emulation-centered like me it's a non issue
and I'd turn the question into:
Is there a (standard) way of generating a JVM dump under Unix?
If so, you may try that under Cygwin.

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

> -----Original Message-----
> From:	Troy Noble [SMTP:troy.noble@channelpoint.com]
> Sent:	Wednesday, July 18, 2001 18:33
> To:	'cygwin@cygwin.com'
> Subject:	RE: broken CTRL-BREAK handling
> 
	[Heribert]  [snip]

> 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.
> 
	[Heribert]  [snip]
>  

--
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/

RE: broken CTRL-BREAK handling

[Troy Noble]

> I don't think that that has ever been a stated goal for cygwin.

That would explain why it has been a non-issue for most folks.
The only product I've ever used on windows that relies no CTRL_BREAK
is Sun's JVM.  Oh, and then there's MKS Toolkit's ksh of course (no,
not the M word!).  Maybe there are other products out there that rely
on ctrl handler, but I suspect it would be rare due to the flakiness
of the console event handling model.  Maybe zsh, tcsh, etc?

> What would a program, ported from UNIX expect in this situation?  With
> your patch, I believe that it would just unceremoniously terminate with
> no way to handle cleanup other than to add windows-specific code for
> dealing with ctrl-break.

Agreed.  However, if CYGWIN=ttl is set they would be fine
since ctrl_c_handler is not en force with that configuration.
If they did not use CYGWIN=ttl and pressed CTRL-BREAK the default
handler provided by Win32 would kick in and terminate the program
as soon as your ctrl_c_handler returned FALSE.

Yet another argument indicating the crippled nature of the whole console
control handler CTRL_*_EVENT model.

Seems like the ideal situation, which I don't think the Win32 API
would let you do, would be:

1. inside ctrl_c_handler check if there is something other than the
   default CtrlHandler and your ctrl_c_handler.  This would definitely
   be the case for the JVM, but not for unix-ported apps.
2. if not, do a SIGTERM within ctrl_c_handler just like you do
   today.  Which means CTRL_BREAK == CTRL_C.
3. if so return FALSE in ctrl_c_handler if type==CTRL_BREAK_EVENT,
   that way the other app-specific control handler would still get
   called.

The Win32 does not have a GetConsoleCtrlHandler or
GetConsoleCtrlHandlers function, so #1 would not be possible
if I read the API docs correctly.

Stalemate.  You've probably thought this through already.

Anyway, given these limitations, it's probably better to live
with the evil you know rather than introduce an evil you
don't.

Yet another argument for withdrawing my CTRL_BREAK proposal.

Thanks, Troy


-----Original Message-----
From: Christopher Faylor [ mailto:cgf@redhat.com ]
Sent: Wednesday, July 18, 2001 10:56 AM
To: cygwin@cygwin.com
Subject: Re: broken CTRL-BREAK handling


On Wed, Jul 18, 2001 at 10:32:35AM -0600, Troy Noble wrote:
>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 don't think that that has ever been a stated goal for cygwin.

What would a program, ported from UNIX expect in this situation?  With
your patch, I believe that it would just unceremoniously terminate with
no way to handle cleanup other than to add windows-specific code for
dealing with ctrl-break.

cgf

--
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/

--
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/

Re: broken CTRL-BREAK handling

[Christopher Faylor]

On Wed, Jul 18, 2001 at 10:32:35AM -0600, Troy Noble wrote:
>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 don't think that that has ever been a stated goal for cygwin.

What would a program, ported from UNIX expect in this situation?  With
your patch, I believe that it would just unceremoniously terminate with
no way to handle cleanup other than to add windows-specific code for
dealing with ctrl-break.

cgf

--
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/

RE: broken CTRL-BREAK handling

[Troy Noble]

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/

RE: broken CTRL-BREAK handling

[Michael Schaap]

At 23:09 17-7-2001, Larry Hall (RFK Partners, Inc) wrote:
>At 04:25 PM 7/17/2001, Puttkammer, Roman wrote:
>
> > > Ah, those were the days.  Everything was so very much better.
> >
> >except for cygwin. it still keeps getting better every single day!
> >sometimes i wonder how long it'll take until somebody ports wine :-)
>
>I vaguely recall the mention of someone investigating this...

That'd be nice!  Than we can run Cygwin under wine under Cygwin.  :-)

  - Michael


--
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/

RE: broken CTRL-BREAK handling

[Larry Hall (RFK Partners, Inc)]

At 04:25 PM 7/17/2001, Puttkammer, Roman wrote:

> > Ah, those were the days.  Everything was so very much better.
>
>except for cygwin. it still keeps getting better every single day!
>sometimes i wonder how long it'll take until somebody ports wine :-)


I vaguely recall the mention of someone investigating this... 



Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX


--
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/

Re: broken CTRL-BREAK handling

[Christopher Faylor]

On Tue, Jul 17, 2001 at 04:14:53PM -0400, Christopher Faylor wrote:
>On Tue, Jul 17, 2001 at 02:06:21PM -0600, Troy Noble wrote:
>>b20.1 handled it differently.  If I press the [X] or
>>CTRL-BREAK in a b20.1 window, JDK dutifully dumps the
>>stack trace.
>
>Hmm.  I'll have to investigate this next week.  I can't easily retrieve
>the B20 sources right now.

Ok.  I lied.  I can check this.  I reverted some sources to around the
B20 time frame.  AFAICT, my original assertion is true.  B20 should
have treated CTRL-BREAK as equivalent to CTRL-C.  If it didn't then
it sure appears to be a bug.  I can't figure out how CTRL-C could work
if CTRL-BREAK wasn't also working the same way.

cgf

--
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/

RE: broken CTRL-BREAK handling

[Puttkammer, Roman]

> Ah, those were the days.  Everything was so very much better.

except for cygwin. it still keeps getting better every single day!
sometimes i wonder how long it'll take until somebody ports wine :-)

--
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/

Re: broken CTRL-BREAK handling

[Christopher Faylor]

On Tue, Jul 17, 2001 at 02:06:21PM -0600, Troy Noble wrote:
>b20.1 handled it differently.  If I press the [X] or
>CTRL-BREAK in a b20.1 window, JDK dutifully dumps the
>stack trace.

Hmm.  I'll have to investigate this next week.  I can't easily retrieve
the B20 sources right now.

>Just one of several things that worked in b20.1 that are
>broken in cygwin 1.x.

I think I recall that back in B20.1 days, people routinely
provided details rather than make vague assertions, too.

Ah, those were the days.  Everything was so very much better.

cgf

--
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/

RE: broken CTRL-BREAK handling

[Troy Noble]

b20.1 handled it differently.  If I press the [X] or
CTRL-BREAK in a b20.1 window, JDK dutifully dumps the
stack trace.

Just one of several things that worked in b20.1 that are
broken in cygwin 1.x.

Troy

-----Original Message-----
From: Christopher Faylor [ mailto:cgf@redhat.com ]
Sent: Tuesday, July 17, 2001 1:37 PM
To: cygwin@cygwin.com
Subject: Re: broken CTRL-BREAK handling


On Tue, Jul 17, 2001 at 01:00:25PM -0600, Troy Noble wrote:
>In exceptions.cc:ctrl_c_handler
>
>I think the following code should be added:
>
>  /* Return FALSE to allow other control handlers to handle CTRL-BREAK */
>  if (type == CTRL_BREAK_EVENT)
>      return FALSE;
>
>before the section of code that checks the pids, sids, pgids etc. and
>eventually culminates in a
>
>      kill (-myself->pid, SIGINT);
>
>Without this code, the current behavior in cygwin 1.3.2 is to send
>SIGINT to the process group whether you press CTRL-C or
>CTRL-BREAK.

Cygwin has considered CTRL-BREAK to be the same thing as CTRL-C for
about five years or so.

The fact that this inconveniences JDK is regrettable but I'm not going
to change well established behavior just to accomodate some non-cygwin
program.

cgf

--
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/

--
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/

Re: broken CTRL-BREAK handling

[Christopher Faylor]

On Tue, Jul 17, 2001 at 01:00:25PM -0600, Troy Noble wrote:
>In exceptions.cc:ctrl_c_handler
>
>I think the following code should be added:
>
>  /* Return FALSE to allow other control handlers to handle CTRL-BREAK */
>  if (type == CTRL_BREAK_EVENT)
>      return FALSE;
>
>before the section of code that checks the pids, sids, pgids etc. and
>eventually culminates in a
>
>      kill (-myself->pid, SIGINT);
>
>Without this code, the current behavior in cygwin 1.3.2 is to send
>SIGINT to the process group whether you press CTRL-C or
>CTRL-BREAK.

Cygwin has considered CTRL-BREAK to be the same thing as CTRL-C for
about five years or so.

The fact that this inconveniences JDK is regrettable but I'm not going
to change well established behavior just to accomodate some non-cygwin
program.

cgf

--
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/

broken CTRL-BREAK handling

[Troy Noble]

In exceptions.cc:ctrl_c_handler

I think the following code should be added:

  /* Return FALSE to allow other control handlers to handle CTRL-BREAK */
  if (type == CTRL_BREAK_EVENT)
      return FALSE;

before the section of code that checks the pids, sids, pgids etc. and
eventually culminates in a

      kill (-myself->pid, SIGINT);

Without this code, the current behavior in cygwin 1.3.2 is to send
SIGINT to the process group whether you press CTRL-C or
CTRL-BREAK.

Certain Win32 programs like JDK's java have their own Ctrl handlers that
watch for CTRL_BREAK_EVENT and dump a stack trace to stdout when
you press CTRL_BREAK or the [X] button in the upper right of the console
window.  Since cygwin's ctrl_c_handler traps the CTRL_BREAK_EVENT
and kills the process group, the JVM never gets a chance to handle the
CTRL_BREAK_EVENT itself.

I have been using the cygwin-1.3.2-1, which is where I saw this.  So
I also checked the latest cvs sources, and it's broken there too.

Thoughts?  Should I submit a patch to this effect?

I have of course patched and recompiled my own DLL, and it works
great.  But thought you might want to know about it too.

Thanks, Troy


--
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/