Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
Message-Id: <5.0.0.25.0.20001211202412.02930eb0@pop.bresnanlink.net>
Date: Mon, 11 Dec 2000 23:21:05 -0600
To: cygwin AT cygwin DOT com
From: Chris Abbey <cabbey AT bresnanlink DOT net>
Subject: [long] Re: signals?
In-Reply-To: <20001113115655.J7424@redhat.com>
References: <4 DOT 3 DOT 2 DOT 7 DOT 0 DOT 20001113000139 DOT 00c3ba60 AT pop DOT bresnanlink DOT net>
 <4 DOT 3 DOT 2 DOT 7 DOT 0 DOT 20001001212519 DOT 00c09bb0 AT pop>
 <4 DOT 3 DOT 2 DOT 7 DOT 0 DOT 20001001212519 DOT 00c09bb0 AT pop>
 <20001002114023 DOT H13304 AT cygnus DOT com>
 <4 DOT 3 DOT 2 DOT 7 DOT 0 DOT 20001113000139 DOT 00c3ba60 AT pop DOT bresnanlink DOT net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

ok, here I go again dredging up an OLD thread... but I still can't figure
this out. We know from previous discussion in the thread that SIGINT is
in fact what is being thrown at the process when I hit ctrl-break, and
that the people who retained the unix "SIGQUIT" naming in the source
code deserve to be flogged with a wet noodle. However, I still feel the
shell (bash) is not treating my process fairly, as it is not allowing it
to complete the handler, but rather is killing it off immediately. For
java developers this renders cygwin a useless environment, because we
can't debug our processes.

At 11:56 11/13/00 -0500, Christopher Faylor wrote:
>Dunno.  Probably, you're sending more than one CTRL-BREAK.  It works fine 
>for me.
>
>cgf

ok, I'd ask that you (and anyone else with a couple minutes) humor me
and try this, I've had about a dozen cygwin users at work try it and
NONE of us have been successful. To start with you'll need a Java Runtime
Environment, if you don't already have one you can get the most excellent
IBM Runtime from the "WebSphere preview technologies downloads" at:
http://www7b.boulder.ibm.com/wsdd/wspvtindex.html (I suppose Sun's
runtime would also work, but I don't know anyone who bothers to run it.)

Take this class:

public class Spinner {
     public static void main(String[] a) throws Throwable {
         while (true) {
             System.out.print('.');
             Thread.sleep(1000);
         }
     }
}

which is available pre-compiled from this url:
http://pws.bresnanlink.net/~cabbey/Spinner.class

if I run this as: "java Spinner" from NT's cmd shell, then hit ctrl-break
while it's running I get this:

D:\HOME>java Spinner
...
Full thread dump Classic VM (J2RE 1.3.0 IBM build cn130-20001124, native 
threads):
     "Finalizer" (TID:0x1568708, sys_thread_t:0x1483ed8, state:CW, native 
ID:0xde) prio=8
         at java.lang.Object.wait(Native Method)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:114)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:129)
         at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:168)

     "Reference Handler" (TID:0x1568750, sys_thread_t:0x1480898, state:CW, 
native ID:0xf3) prio=10
         at java.lang.Object.wait(Native Method)
         at java.lang.Object.wait(Object.java:421)
         at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)

     "Signal dispatcher" (TID:0x1568798, sys_thread_t:0x147e270, state:R, 
native ID:0x7c) prio=5

     "main" (TID:0x15687e0, sys_thread_t:0x753348, state:CW, native 
ID:0x113) prio=5
         at java.lang.Thread.sleep(Native Method)
         at Spinner.main(Spinner.java:5)


Monitor pool info:
   Initial monitor count: 32
   Minimum number of free monitors before expansion: 5
   Pool will next be expanded by: 16
   Current total number of monitors: 32
   Current number of free monitors: 29

Monitor Pool Dump (inflated object-monitors):
   sys_mon_t:0x00761260 infl_mon_t: 0x00752d90:
     java.lang.ref.Reference$Lock AT 15701C8/15701D0: <unowned>
         Waiting to be notified:
             "Reference Handler" (0x1480898)
   sys_mon_t:0x00761280 infl_mon_t: 0x00752db0:
     java.lang.ref.ReferenceQueue$Lock AT 156FE18/156FE20: <unowned>
         Waiting to be notified:
             "Finalizer" (0x1483ed8)

JVM System Monitor Dump (registered monitors):
     ACS Heap lock: <unowned>
     System Heap lock: <unowned>
     Sleep lock: <unowned>
         Waiting to be notified:
             "main" (0x753348)
     Method trace lock: <unowned>
     UTF8 Cache lock: <unowned>
     Heap lock: <unowned>
     Rewrite Code lock: <unowned>
     Monitor Cache lock: owner "Signal dispatcher" (0x147e270) 1 entry
     JNI Pinning lock: <unowned>
     JNI Global Reference lock: <unowned>
     Classloader lock: <unowned>
     Linking class lock: <unowned>
     Binclass lock: <unowned>
     Monitor Registry lock: owner "Signal dispatcher" (0x147e270) 1 entry
     Thread queue lock: owner "Signal dispatcher" (0x147e270) 1 entry

Thread identifiers (as used in flat monitors):
     ident 5 "Finalizer" (0x1483ed8) ee 0x01483d08
     ident 4 "Reference Handler" (0x1480898) ee 0x014806c8
     ident 3 "Signal dispatcher" (0x147e270) ee 0x0147e0a0
     ident 2 "main" (0x753348) ee 0x00753178

Java Object Monitor Dump (flat & inflated object-monitors):
     java.lang.ref.ReferenceQueue$Lock AT 156FE18/156FE20
         locknflags 80000300 Monitor inflated infl_mon 0x00752db0
     java.lang.ref.Reference$Lock AT 15701C8/15701D0
         locknflags 80000200 Monitor inflated infl_mon 0x00752d90

....
D:\HOME>

Note the three dots before the thread break, and the four dots afterward,
then I hit ctrl-c to end it. That's normal, correct behavior... here's a
second run, slightly trimmed:

D:\HOME>java Spinner
...
Full thread dump Classic VM (J2RE 1.3.0 IBM build cn130-20001124, native 
threads):
     "Finalizer" (TID:0x1568708, sys_thread_t:0x1485ac0, state:CW, native 
ID:0xc9)
[...]
java.lang.ref.Reference$Lock AT 15701C8/15701D0
         locknflags 80000200 Monitor inflated infl_mon 0x00752db0

...
Full thread dump Classic VM (J2RE 1.3.0 IBM build cn130-20001124, native 
threads):
     "Finalizer" (TID:0x1568708, sys_thread_t:0x1485ac0, state:CW, native 
ID:0xc9)
[...]
     java.lang.ref.Reference$Lock AT 15701C8/15701D0
         locknflags 80000200 Monitor inflated infl_mon 0x00752db0

...
Full thread dump Classic VM (J2RE 1.3.0 IBM build cn130-20001124, native 
threads):
     "Finalizer" (TID:0x1568708, sys_thread_t:0x1485ac0, state:CW, native 
ID:0xc9)
[...]
     java.lang.ref.Reference$Lock AT 15701C8/15701D0
         locknflags 80000200 Monitor inflated infl_mon 0x00752db0

...
Full thread dump Classic VM (J2RE 1.3.0 IBM build cn130-20001124, native 
threads):
     "Finalizer" (TID:0x1568708, sys_thread_t:0x1485ac0, state:CW, native 
ID:0xc9)
[...]
     java.lang.ref.Reference$Lock AT 15701C8/15701D0
         locknflags 80000200 Monitor inflated infl_mon 0x00752db0

....
D:\HOME>

now, just in the interest of space I've cut out the majority of the
dumps, but you can clearly see that I let it sit idle for three seconds,
then took a dump, sit idle, took a dump, etc... before killing it.

Now here's what I get with bash under cygwin:

~ $ java Spinner
....
Full thread dump Classic VM (J2RE 1.3.0 IBM build cn130-20001124, native 
threads):
     "Finalizer" (TID:0x1568708, sys_thread_t:0x14858b8, state:CW, native 
ID:0xc0) prio=8
         at java.lang.Object.wait(Native Method)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:114)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:129)
         at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:168)


~ $

Now sometimes it's not that short, on an IDLE system (and this is a dual
processor machine) it can sometimes get farther:
~ $ java Spinner
...
Full thread dump Classic VM (J2RE 1.3.0 IBM build cn130-20001124, native 
threads):
     "Finalizer" (TID:0x1568708, sys_thread_t:0x14858b8, state:CW, native 
ID:0xde) prio=8
         at java.lang.Object.wait(Native Method)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:114)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:129)
         at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:168)

     "Reference Handler" (TID:0x1568750, sys_thread_t:0x1481120, state:CW, 
native ID:0x113) prio=10
         at java.lang.Object.wait(Native Method)
         at java.lang.Object.wait(Object.java:421)
         at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)

     "Signal dispatcher" (TID:0x1568798, sys_thread_t:0x1472b90, state:R, 
native ID:0xf3) prio=5

     "main" (TID:0x15687e0, sys_thread_t:0x753030, state:CW, native 
ID:0x78) prio=5
         at java.lang.Thread.sleep(Native Method)
         at Spinner.main(Spinner.java:5)


Monitor pool info:
   Initial monitor count: 32
   Minimum number of free monitors before expansion: 5
   Pool will next be expanded by: 16
   Current total number of monitors: 32
   Current number of free monitors: 29

Monitor Pool Dump (inflated object-monitors):
   sys_mon_t:0x00761880 infl_mon_t: 0x00752a78:
     java.lang.ref.Reference$Lock AT 15701C8/15701D0: <unowned>
         Waiting to be notified:
             "Reference Handler" (0x1481120)
   sys_mon_t:0x007618a0 infl_mon_t: 0x00752a98:
     java.lang.ref.ReferenceQueue$Lock AT 156FE18/156FE20: <unowned>
         Waiting to be notified:
             "Finalizer" (0x14858b8)

JVM System Monitor Dump (registered monitors):
     ACS Heap lock: <unowned>
     System Heap lock: <unowned>
     Sleep lock: <unowned>
         Waiting to be notified:
             "main" (0x753030)
     Method trace lock: <unowned>
     UTF8 Cache lock: <unowned>
     Heap lock: <unowned>
     Rewrite Code lock: <unowned>
     Monitor Cache lock: owner "Signal dispatcher" (0x1472b90) 1 entry
     JNI Pinning lock: <unowned>
     JNI Global Reference lock: <unowned>
     Classloader lock: <unowned>
     Linking class lock: <unowned>
     Binclass lock: <unowned>
     Monitor Registry lock: owner "Signal dispatcher" (0x1472b90) 1 entry
     Thread queue lock: owner "Signal dispatcher" (0x1472b90) 1 entry

Thread identifiers (as used in flat monitors):
     ident 5 "Finalizer" (0x14858b8) ee 0x014856e8
     ident 4 "Reference Handler" (0x1481120) ee 0x01480f50
     ident 3 "Signal dispatcher" (0x1472b90) ee 0x014729c0


~ $

but note that it was STILL thrown back to the shell. Once it's even finished
this *trivial* dump, but never when I'm running hundreds of threads. Now 
instead
of using ctrl-break, let's switch to "kill -INT <pid>"...

~ $ java Spinner
........
~ $

now it took a little longer to switch terminals, do the ps and type the 
command,
but as soon as I hit enter on the kill command, both windows returned the 
command
prompt. This one never does get anything printed out.

I've walked through all the signals available to me from kill and gotten some
interesting results, my favorites have been SIGQUIT (3), SIGABRT (5) which 
resulted in
bash generating a "java.exe.stackdump" long before the JVM actually ended!

~ $ java Spinner
.......      0 [sig] bash 283! stackdump: Dumping stack trace to 
java.exe.stackdump
...Quit (core dumped)
~ $

kill -2 exited the jvm, looks to be the same as ctrl-c, which jives with what
Chris said earlier; 9, 15, 16, 27 all killed it in some fashion... None of
them resulted in even an attempt at a thread dump.

In the windows world they want an INTERUPT SIGNAL. How the heck do I
generate it under cygwin, without causing bash to kill the job off?

Oh, and just for fun I tried this under /bin/sh and it works just fine with
ctrl-break. signals 1, 4-15, 24-27, 29-31 all caused it to exit in one way
or another. Except of course that this only works if you're on the console;
otherwise it just kills the telnet session....

Can anyone suggest a method to accomplish the same thing as ctrl-break from a
command line?


now the forces of openness
     have a powerful and
     unexpected new ally
    http://ibm.com/linux/


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com