Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <8F23E55D511AD5119A6800D0B76FDDE1CA2EF8@cpex3.channelpoint.com>
From: Troy Noble <troy DOT noble AT channelpoint DOT com>
To: "'Heribert Dahms'" <heribert_dahms AT icon-scm DOT com>,
        Troy Noble
	 <troy DOT noble AT channelpoint DOT com>,
        "'cygwin AT cygwin DOT com'" <cygwin AT cygwin DOT com>
Subject: RE: broken CTRL-BREAK handling
Date: Wed, 18 Jul 2001 15:01:33 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/)

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 AT icon-scm DOT com]
Sent: Wednesday, July 18, 2001 2:42 PM
To: 'Troy Noble'; 'cygwin AT cygwin DOT 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 AT icon-gmbh DOT de)

> -----Original Message-----
> From:	Troy Noble [SMTP:troy DOT noble AT channelpoint DOT com]
> Sent:	Wednesday, July 18, 2001 18:33
> To:	'cygwin AT cygwin DOT 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/