Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #29869 > unrolled thread

refusal to quit

Started byRoedy Green <see_website@mindprod.com.invalid>
First post2014-08-29 09:56 -0700
Last post2014-09-02 12:17 +0200
Articles 14 — 6 participants

Back to article view | Back to comp.lang.java.programmer


Contents

  refusal to quit Roedy Green <see_website@mindprod.com.invalid> - 2014-08-29 09:56 -0700
    Re: refusal to quit Mike Amling <mamling@chaff.us> - 2014-08-29 12:50 -0500
      Re: refusal to quit Roedy Green <see_website@mindprod.com.invalid> - 2014-08-31 11:31 -0700
        Re: refusal to quit Josip Almasi <joe@vrspace.org> - 2014-09-01 17:14 +0200
          Re: refusal to quit Roedy Green <see_website@mindprod.com.invalid> - 2014-09-01 16:37 -0700
    Re: refusal to quit Josip Almasi <joe@vrspace.org> - 2014-08-29 22:16 +0200
      Re: refusal to quit Roedy Green <see_website@mindprod.com.invalid> - 2014-08-31 11:32 -0700
        Re: refusal to quit Josip Almasi <joe@vrspace.org> - 2014-09-01 17:20 +0200
    Re: refusal to quit Knute Johnson <eternal@knutejohnson.com> - 2014-08-29 17:25 -0700
    Re: refusal to quit Roedy Green <see_website@mindprod.com.invalid> - 2014-09-01 14:20 -0700
      Re: refusal to quit Roedy Green <see_website@mindprod.com.invalid> - 2014-09-01 14:34 -0700
      Re: refusal to quit Josip Almasi <joe@vrspace.org> - 2014-09-02 10:49 +0200
      Re: refusal to quit Arne Vajhøj <arne@vajhoej.dk> - 2014-09-07 22:04 -0400
    Re: refusal to quit Jan Burse <janburse@fastmail.fm> - 2014-09-02 12:17 +0200

#29869 — refusal to quit

FromRoedy Green <see_website@mindprod.com.invalid>
Date2014-08-29 09:56 -0700
Subjectrefusal to quit
Message-ID<u1c10ap9r3l11teuhngbr5on958vu8h2vj@4ax.com>
Sometimes programs simply refuse to quit after main has terminated. 

Sometimes the app is single-thread so I am baffled what it is waiting
for.

Practically I can make things work by adding a System.exit(0)
as the last thing in main.

However, I would like to understand what is going on.  Is there a way
to shed some light on why a program won't quit?
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Errors using inadequate data are much less than those using no data at all. 
~ Charles Babbage (born: 1791-12-26 died: 1871-10-18 at age: 79)

[toc] | [next] | [standalone]


#29870

FromMike Amling <mamling@chaff.us>
Date2014-08-29 12:50 -0500
Message-ID<c6bspsF39diU2@mid.individual.net>
In reply to#29869
On 8/29/14 11:56 AM, Roedy Green wrote:
> Sometimes programs simply refuse to quit after main has terminated.
>
> Sometimes the app is single-thread so I am baffled what it is waiting
> for.
>
> Practically I can make things work by adding a System.exit(0)
> as the last thing in main.
>
> However, I would like to understand what is going on.  Is there a way
> to shed some light on why a program won't quit?

You're sure it hasn't started some other Thread under the covers, e.g. a 
la Swing? I'd start out with a census of the running Threads.

--Mike Amling
QnV0IHRoZW4sIHdoYXQgZG8gSSBrbm93Pw==

[toc] | [prev] | [next] | [standalone]


#29880

FromRoedy Green <see_website@mindprod.com.invalid>
Date2014-08-31 11:31 -0700
Message-ID<n3q60ahdlkju3i2dh9f088p0g96262h1p6@4ax.com>
In reply to#29870
On Fri, 29 Aug 2014 12:50:24 -0500, Mike Amling <mamling@chaff.us>
wrote, quoted or indirectly quoted someone who said :

>You're sure it hasn't started some other Thread under the covers, e.g. a 
>la Swing? I'd start out with a census of the running Threads.

One program that did this had been behaving itself for years.  I ran
it in debug mode. I put a breakpoint just before exit. Only one
thread. The program has only one thread and no GUI. Tis a puzzlement.
I solved it with brute force by putting System.exit(0) as the last
statement in main.

In another case, I set up a timer to periodically check for the
existence of a please-stop gracefully file. I had to remember to
cancel the timer.  

I am beginning to wonder if there is a problem in the latest JDK (or
possibly Jet. I need to rule that out definitively).
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Errors using inadequate data are much less than those using no data at all. 
~ Charles Babbage (born: 1791-12-26 died: 1871-10-18 at age: 79)

[toc] | [prev] | [next] | [standalone]


#29884

FromJosip Almasi <joe@vrspace.org>
Date2014-09-01 17:14 +0200
Message-ID<lu22h7$bdc$2@gregory.bnet.hr>
In reply to#29880
On 08/31/2014 08:31 PM, Roedy Green wrote:
> On Fri, 29 Aug 2014 12:50:24 -0500, Mike Amling <mamling@chaff.us>
> wrote, quoted or indirectly quoted someone who said :
>
>> You're sure it hasn't started some other Thread under the covers, e.g. a
>> la Swing? I'd start out with a census of the running Threads.
>
> One program that did this had been behaving itself for years.  I ran
> it in debug mode. I put a breakpoint just before exit. Only one
> thread. The program has only one thread and no GUI. Tis a puzzlement.

Can't catch shutdown hook that way.

Regards...

[toc] | [prev] | [next] | [standalone]


#29888

FromRoedy Green <see_website@mindprod.com.invalid>
Date2014-09-01 16:37 -0700
Message-ID<qi0a0a5rt2r0d5074ac0e0deb1phbpa4o1@4ax.com>
In reply to#29884
On Mon, 01 Sep 2014 17:14:47 +0200, Josip Almasi <joe@vrspace.org>
wrote, quoted or indirectly quoted someone who said :

>Can't catch shutdown hook that way.

There is some very strange things I am seeing just before
System.exit(). A Timer where there is no Timer instance anywhere.  It
must belong to some library code.

But at least most of the code is now shutting down cleanly.

I got rid of the shutdown hook.  I think that code was getting run
very late in the game.

-- 
Roedy Green Canadian Mind Products http://mindprod.com
Errors using inadequate data are much less than those using no data at all. 
~ Charles Babbage (born: 1791-12-26 died: 1871-10-18 at age: 79)

[toc] | [prev] | [next] | [standalone]


#29871

FromJosip Almasi <joe@vrspace.org>
Date2014-08-29 22:16 +0200
Message-ID<ltqn23$88m$1@gregory.bnet.hr>
In reply to#29869
On 08/29/2014 06:56 PM, Roedy Green wrote:
> Sometimes programs simply refuse to quit after main has terminated.
>
> Sometimes the app is single-thread so I am baffled what it is waiting
> for.
>
> Practically I can make things work by adding a System.exit(0)
> as the last thing in main.
>
> However, I would like to understand what is going on.  Is there a way
> to shed some light on why a program won't quit?

Yep, start jconsole and inspect threads, there must be some running, 
started implicitly by some lib.

Regards...

[toc] | [prev] | [next] | [standalone]


#29881

FromRoedy Green <see_website@mindprod.com.invalid>
Date2014-08-31 11:32 -0700
Message-ID<ugq60a9jv25ksbekvjd3vitcsjo98cl4lb@4ax.com>
In reply to#29871
On Fri, 29 Aug 2014 22:16:03 +0200, Josip Almasi <joe@vrspace.org>
wrote, quoted or indirectly quoted someone who said :

>Yep, start jconsole and inspect threads, there must be some running, 
>started implicitly by some lib.

Could you recommend a tutorial on using JConsole?
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Errors using inadequate data are much less than those using no data at all. 
~ Charles Babbage (born: 1791-12-26 died: 1871-10-18 at age: 79)

[toc] | [prev] | [next] | [standalone]


#29885

FromJosip Almasi <joe@vrspace.org>
Date2014-09-01 17:20 +0200
Message-ID<lu22rm$bq6$1@gregory.bnet.hr>
In reply to#29881
On 08/31/2014 08:32 PM, Roedy Green wrote:
> On Fri, 29 Aug 2014 22:16:03 +0200, Josip Almasi <joe@vrspace.org>
> wrote, quoted or indirectly quoted someone who said :
>
>> Yep, start jconsole and inspect threads, there must be some running,
>> started implicitly by some lib.
>
> Could you recommend a tutorial on using JConsole?

Err, uh, I can't:/
But it's simple, just start, click on threads, see stack... well at 
least it's simple as long you run it on the same box as the app.
X run thru ssh so I never tried it remote.

Regards...

[toc] | [prev] | [next] | [standalone]


#29872

FromKnute Johnson <eternal@knutejohnson.com>
Date2014-08-29 17:25 -0700
Message-ID<ltr5lu$iq0$1@dont-email.me>
In reply to#29869
On 8/29/2014 09:56, Roedy Green wrote:
> Sometimes programs simply refuse to quit after main has terminated.
>
> Sometimes the app is single-thread so I am baffled what it is waiting
> for.
>
> Practically I can make things work by adding a System.exit(0)
> as the last thing in main.
>
> However, I would like to understand what is going on.  Is there a way
> to shed some light on why a program won't quit?
>

Timers, Threads (even daemon threads sometimes although they aren't 
supposed to stop shutdown), EDT held on undisposed JFrames or JDialogs. 
  Sometimes finding them all can be a pain.

I pretty much don't use System.exit anymore so that I'm forced to find 
all the running things and shut them off so the program will quit.

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]


#29886

FromRoedy Green <see_website@mindprod.com.invalid>
Date2014-09-01 14:20 -0700
Message-ID<7lo90apm56ne18c2fl7nk2o2adqghe0mkq@4ax.com>
In reply to#29869
On Fri, 29 Aug 2014 09:56:45 -0700, Roedy Green
<see_website@mindprod.com.invalid> wrote, quoted or indirectly quoted
someone who said :

>Sometimes programs simply refuse to quit after main has terminated. 

I sprinkled a call to this code in every main.

    /**
     * call just before System.exit( 0 ) to find out if there was more
than one thread.
     */
    public static void trackLastThread()
        {
        final int activeCount = Thread.activeCount();
        if ( activeCount == 1 )
            {
            return;
            }
        else
            {
            out.println( activeCount + " threads " );
            }
        final Thread[] ta = new Thread[ activeCount ];
        Thread.enumerate( ta );
        for ( Thread t : ta )
            {
            out.println( "T H R E A D" );
            out.println( t.toString() );
            final StackTraceElement[] s = t.getStackTrace();
            for ( StackTraceElement e : s )
                {
                out.println( e.toString() );
                }
            out.println();
            }
        }  // /method

In one case it said that a Timer was still running.  I thought
Timer.cancel would be sufficient to kill it, but apparently not.
I gather it just stops the periodic calls to run, but leaves the
thread alive.

-- 
Roedy Green Canadian Mind Products http://mindprod.com
Errors using inadequate data are much less than those using no data at all. 
~ Charles Babbage (born: 1791-12-26 died: 1871-10-18 at age: 79)

[toc] | [prev] | [next] | [standalone]


#29887

FromRoedy Green <see_website@mindprod.com.invalid>
Date2014-09-01 14:34 -0700
Message-ID<4ep90a55sd12b8vn5026iqb919m16lp5uf@4ax.com>
In reply to#29886
On Mon, 01 Sep 2014 14:20:32 -0700, Roedy Green
<see_website@mindprod.com.invalid> wrote, quoted or indirectly quoted
someone who said :

>In one case it said that a Timer was still running.  I thought
>Timer.cancel would be sufficient to kill it, but apparently not.
>I gather it just stops the periodic calls to run, but leaves the
>thread alive.
I found a work-around for that.
Instead of Timer, I used:

   ScheduledExecutorService scheduler;
...
   scheduler = Executors.newSingleThreadScheduledExecutor();
   scheduler.scheduleAtFixedRate( aRunnable, 5, 5, TimeUnit.SECONDS );
...
   // shutdown that kills both timer and thread     
   scheduler.shutdownNow();
       
   
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Errors using inadequate data are much less than those using no data at all. 
~ Charles Babbage (born: 1791-12-26 died: 1871-10-18 at age: 79)

[toc] | [prev] | [next] | [standalone]


#29889

FromJosip Almasi <joe@vrspace.org>
Date2014-09-02 10:49 +0200
Message-ID<lu40ab$42b$1@gregory.bnet.hr>
In reply to#29886
On 09/01/2014 11:20 PM, Roedy Green wrote:
> On Fri, 29 Aug 2014 09:56:45 -0700, Roedy Green
> <see_website@mindprod.com.invalid> wrote, quoted or indirectly quoted
> someone who said :
>
>> Sometimes programs simply refuse to quit after main has terminated.
>
> I sprinkled a call to this code in every main.

...

> In one case it said that a Timer was still running.  I thought
> Timer.cancel would be sufficient to kill it, but apparently not.
> I gather it just stops the periodic calls to run, but leaves the
> thread alive.

Now that's funny. Check this:

   public void cancel() {
         synchronized(queue) {
             thread.newTasksMayBeScheduled = false;
             queue.clear();
             queue.notify();  // In case queue was already empty.
         }
   }

So it just wakes up all threads and will not run them again.
Since queue is private, I suppose only thread waiting for it may be 
inner TimerThread.
Main loop terminates allright, but that's it.
What really happens depends on TimerTask.run() implementation.

BTW mainLoop() catches InterruptedException and ignores it.

Regards...

[toc] | [prev] | [next] | [standalone]


#29927

FromArne Vajhøj <arne@vajhoej.dk>
Date2014-09-07 22:04 -0400
Message-ID<540d0e90$0$298$14726298@news.sunsite.dk>
In reply to#29886
On 9/1/2014 5:20 PM, Roedy Green wrote:
> In one case it said that a Timer was still running.  I thought
> Timer.cancel would be sufficient to kill it, but apparently not.
> I gather it just stops the periodic calls to run, but leaves the
> thread alive.

Hm.

Here one thread is created per Timer and when cancel is called
then the thread is stopped.

What Java did you see that happening on?

Arne

PS: Timer has a constructor where you can specify the thread to be
     a daemon thread!

[toc] | [prev] | [next] | [standalone]


#29890

FromJan Burse <janburse@fastmail.fm>
Date2014-09-02 12:17 +0200
Message-ID<lu45fa$t92$1@news.albasani.net>
In reply to#29869
Roedy Green schrieb:
> Sometimes programs simply refuse to quit after main has terminated.
>
> Sometimes the app is single-thread so I am baffled what it is waiting
> for.
>
> Practically I can make things work by adding a System.exit(0)
> as the last thing in main.
>
> However, I would like to understand what is going on.  Is there a way
> to shed some light on why a program won't quit?
>

I had the same problem once. It turned out that there
was a pop up menu still around, which made the runtime
think that swing is still running.

And the problem was not persistent to all platforms among
Linux, Windows and Mac. If I remember well it happened
only on windows.

Don't remember the JRE version though. The problem was
very subtle and I solved it by moving the field holding
the pop up from a static variable to a class instance
variable, of a frame.

Now each of my frame has its own local pop up, and the
problem seems to be gone. But a little bit more ram
is needed when multiple frames are open, and when they
use the same pop up.

Bye

BTW: I also noticed that pop ups don't receive tree
traversal events. So I needed to call SwingUtilities
updateComponentTreeUI extra on the pop ups.

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.java.programmer


csiph-web