JVM Crash During X11 Shutdown

Fedora 12
JRE/JDK 7u7
GeForce 9800 GT + NVIDIA driver 304.37
JOGAMP/JOGL custom build from 09/17/2012 repos

While testing a build from repos cloned on 09/17/2012 to see if Sven's fix for Bug 615 worked (it did; comments forthcoming in that bug) I started getting JVM dumps while shutting down our graphics app.

I needed two X screens configured to test the bug fix, but I verified that this crash also happens with a single screen configured.

The crashes happen on every shutdown, and always includes something like this at the top of the hs_err_pid... file:

C  [libGL.so.1+0x70d71]  fileno+0x70d71
C  [libnativewindow_x11.so+0x319a]  Java_jogamp_nativewindow_x11_X11Lib_XCloseDisplay__J+0x75
j  jogamp.nativewindow.x11.X11Lib.XCloseDisplay(J)I+0
j  jogamp.nativewindow.x11.X11Util.XCloseDisplay(J)I+66
j  jogamp.nativewindow.x11.X11Util.closePendingDisplayConnections()I+117
j  jogamp.nativewindow.x11.X11Util.shutdown()V+213
...more stuff...

The complete hs_err_pid file from which this snippet was taken is here.

The previous JOGL version we were running with was RC10 plus our initial fix for Bug 615, and it didn't have any shutdown issues.

A diff of X11Lib.java between our RC10 version and the 09/17 version reveals that quite a bit has changed related to X11 shutdown.

Has anyone seen similar crashes?

Hi

I will give it a try on a similar configuration but I have to update my game in order to use this version.

On 09/19/2012 07:51 PM, rhatcher [via jogamp] wrote: Yes, this is unrelated to Bug 615 - and confirmed.

You are probably seeing something on stderr before the crash,
i.e. non closed X11 display connections ?

Yup, X11Util is a bit to harsh now, even closing the connections
w/o close attempt. Usually we only tried to close those which were pending.
This was due to the ATI bug .. probably too much :)

~Sven

Sven Gothel wrote

Yup, X11Util is a bit to harsh now, even closing the connections
w/o close attempt. Usually we only tried to close those which were pending.
This was due to the ATI bug .. probably too much :)

I already observed that some months ago, it has nothing to do with recent changes but it was not causing any hard crash of the JVM.

On 09/20/2012 10:48 AM, gouessej [via jogamp] wrote:
>     Sven Gothel wrote
>     Yup, X11Util is a bit to harsh now, even closing the connections
>     w/o close attempt. Usually we only tried to close those which were pending.
>     This was due to the ATI bug .. probably too much :)
>
> I already observed that some months ago, it has nothing to do with recent
> changes but it was not causing any hard crash of the JVM.

Ofc .. all this points to your code, not releasing all 'JOGL' resources,
i.e. drawables etc ..
However, we should not crash the JVM .. given.

~Sven

Sven/Julien, thanks for the feedback.

> Sven wrote:
> Ofc .. all this points to your code, not releasing all 'JOGL' resources,
> i.e. drawables etc ..

OK - I will investigate.  Previous JOGL implementations obviously were more... forgiving :-).  Our system has many components, so it's easy to believe something may be lingering at shutdown.


> However, we should not crash the JVM .. given.

Agree.  Not that it is an excuse for leaving resources lying around, but if it were mandatory for apps to clean up at shutdown to avoid a crash then there probably wouldn't be a C or C++ program anywhere in sight.  Heh.


All humor aside, should a bug be filed against this crash?

On 09/20/2012 04:56 PM, rhatcher [via jogamp] wrote: Yes, thank you, much appreciated.

Will fix this soon.

~Sven

This begs another question though:

I assume the shutdown responsibility of well-behaved JOGL graphics components is to implement "dispose" and make sure everything is cleaned up there, but the responsibility for calling dispose lies elsewhere.

I experimented with this some in a small test app and it looked like dispose won't get called unless either the frame containing the GLCanvas is disposed explicitly or the canvas itself is disposed explicitly (?).  IOW unless I had a window listener like this:

    private class TestWindowAdapter extends WindowAdapter
    {
        @Override
        public void windowClosing( WindowEvent e )
        {
            new Thread( new Runnable() {
                public void run() {
                    _animator.stop() ;
                    _graphicsFrame.dispose() ;
                    System.exit(0) ;
                }
            } ).start() ;
        }
    }

...and a File->Quit handler like this:

    quitMenuItem.addActionListener( new ActionListener() {
        public void actionPerformed( ActionEvent event ) {
            new Thread( new Runnable() {
                public void run() {
                    _animator.stop() ;
                    _graphicsFrame.dispose() ;
                    System.exit(0) ;
                }
            } ).start() ;
        }
    } ) ;

...i.e. that called _graphicsFrame.dispose() explicitly, then dispose() in my GLEventListener didn't get called, and I still got the crash.

So, even if the various listeners implement dispose() this cleanup is not exactly automatic and some careful setup is required to make sure it happens.

I ran the Gears/JGears demo and it crashed at shutdown too (and the Gears dispose method didn't get called) until I added an explicit dispose call on the frame.

On 09/21/2012 12:25 AM, rhatcher [via jogamp] wrote:
> This begs another question though:
>
> I assume the shutdown responsibility of well-behaved JOGL graphics components
> is to implement "dispose" and make sure everything is cleaned up there,

We are talking about AWT, I see :) .. YES
1) Don't do it in another thread @ windowClosing, it's too late
2) Don't call System.exit(0) ..

 setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); // Swing JFrame only (I guess)

 // close nicely w/ GLCanvas destruction
 addWindowListener(new WindowAdapter() {
    public void windowClosing(WindowEvent e) {
       getContentPane().remove(fCanvas); // Swing JFrame !
       remove(fCanvas); // AWT Frame !
    }
 });

Then it should work ..

> ...i.e. that called _graphicsFrame.dispose() explicitly, then dispose() in my
> GLEventListener didn't get called, and I still got the crash.
>
> So, even if the various listeners implement dispose() this cleanup is not
> exactly automatic and some careful setup is required to make sure it happens.
>
> I ran the Gears/JGears demo and it crashed at shutdown too (and the Gears
> dispose method didn't get called) until I added an explicit dispose call on
> the frame.

It's possible that we haven't added nice shutdown there .. :)
Will look into the Gears* demos _in_ the unit tests.

Ping you back when done.

~Sven

Sven Gothel wrote

2) Don't call System.exit(0) ..

It's mandatory in Java Web Start applications, we must do it.

Sven wrote:
> We are talking about AWT, I see :)

Heh.  Yeah - it's a decade-old pile of legacy goo.  We currently are working on replacing our Swing/AWT UIs with E4/SWT, mostly to get the nice real-estate management features.  And we are an Eclipse shop so there's some synergy there.

In the meantime I'm primarily interested in figuring out the pattern/recipe required in Swing/AWT apps to guarantee clean shut-down through all possible normal exit scenarios (X button, ALT+F4 (same thing I guess), or File-Quit handler, or ESC key, or whatever).  Then I can go fix all affected spots in the interests of stopping further propagation of the wrong approach through the copy/paste/modify "reuse technique".


> 1) Don't do it in another thread @ windowClosing, it's too late
> 2) Don't call System.exit(0) ..

I borrowed both of these from the JGears demo (copy/paste/modify strikes again).  Not all of the demos do these things, but many do.

I only ran the JGears demo, but I also poked around in the other demo code and on inspection got the impression that a majority may not be handling shutdown/cleanup correctly (?).  I could be totally off the mark about this because I didn't have time to run all of them.

In the jogl-demos I cloned yesterday there are 108 demo classes that appear to create JFrames, so checking them all, fixing the offenders, and doing the testing would take a chunk of time.


>  setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); // Swing JFrame only (I guess)
>
> // close nicely w/ GLCanvas destruction
> addWindowListener(new WindowAdapter() {
>   public void windowClosing(WindowEvent e) {
>     getContentPane().remove(fCanvas); // Swing JFrame !
>     remove(fCanvas); // AWT Frame !
>   }
> });

Tweeking my test app to add your suggestions above also shut down cleanly, so I'll proceed with that.  Though... there is still the issue of whether or not to call System.exit based on Julien's comment.

I'll keep an ear on this topic for further wisdom.

rhatcher wrote

Though... there is still the issue of whether or not to call System.exit based on Julien's comment.

If you don't call System.exit(), the heavy process running your Java application launched with Java Web Start won't be stopped.

I get this when leaving TUER:
 [java] X11Util.Display: Shutdown (JVM shutdown: true, open (no close attempt): 2/2, reusable (open, marked uncloseable): 0, pending (post closing): 2)
     [java] X11Util: Open X11 Display Connections: 2
     [java] X11Util: Open[0]: NamedX11Display[:0, 0xffffffffa043aa50, refCount 1, unCloseable false]
     [java] X11Util: Open[1]: NamedX11Display[:0, 0xffffffffa0438d20, refCount 1, unCloseable false]
     [java] X11Util: Reusable X11 Display Connections: 0
     [java] X11Util: Pending X11 Display Connections (creation order): 2
     [java] X11Util: Pending[0]: NamedX11Display[:0, 0xffffffffa043aa50, refCount 1, unCloseable false]
     [java] X11Util: Pending[1]: NamedX11Display[:0, 0xffffffffa0438d20, refCount 1, unCloseable false]
     [java] Nativewindow X11 IOError (Thread main-Display-jogamp.newt.driver.x11_:0-2-EDT-1): Display 0xa0438d20 (:0): Resource temporarily unavailable
     [java] java.lang.Exception: Stack trace
     [java] at java.lang.Thread.dumpStack(Thread.java:1266)
     [java] at jogamp.nativewindow.x11.X11Util.dumpStack(X11Util.java:564)
     [java] at jogamp.newt.driver.x11.DisplayDriver.DispatchMessages0(Native Method)
     [java] at jogamp.newt.driver.x11.DisplayDriver.dispatchMessagesNative(DisplayDriver.java:131)
     [java] at jogamp.newt.DisplayImpl.dispatchMessages(DisplayImpl.java:435)
     [java] at jogamp.newt.DisplayImpl$DispatchMessagesRunnable.run(DisplayImpl.java:365)
     [java] at jogamp.newt.DefaultEDTUtil$EventDispatchThread.run(DefaultEDTUtil.java:293)
     [java] Nativewindow X11 IOError (Thread main-Display-jogamp.newt.driver.x11_:0-2-EDT-1): Display 0xa0438d20 (:0): Resource temporarily unavailable
     [java] FATAL ERROR in native method: Nativewindow X11 IOError (Thread main-Display-jogamp.newt.driver.x11_:0-2-EDT-1): Display 0xa0438d20 (:0): Resource temporarily unavailable
     [java] at jogamp.newt.driver.x11.DisplayDriver.DispatchMessages0(Native Method)
     [java] at jogamp.newt.driver.x11.DisplayDriver.dispatchMessagesNative(DisplayDriver.java:131)
     [java] at jogamp.newt.DisplayImpl.dispatchMessages(DisplayImpl.java:435)
     [java] at jogamp.newt.DisplayImpl$DispatchMessagesRunnable.run(DisplayImpl.java:365)
     [java] at jogamp.newt.DefaultEDTUtil$EventDispatchThread.run(DefaultEDTUtil.java:293)

BUILD FAILED
/home/gouessej/Documents/programmation/java/workspace/tuer/build.xml:452: Java returned: 134

On 09/23/2012 12:09 PM, gouessej [via jogamp] wrote: with the latest code, i.e. fix for the shutdown ?
<http://jogamp.org/git/?p=jogl.git;a=commit;h=ba846a478d616327817dd530dbdcd9a786be5b7a>

you are getting this w/ an ATI driver ?
(pending X11 display closing is performed only for those now)

~Sven

Sorry I use the latest aggregated build which does not contain this fix. I use open source Xorg driver for my ATI Radeon 9250 Pro, I have no other choice as the proprietary driver is no more provided with my distro (Mageia Linux 2).

On 09/24/2012 01:00 AM, gouessej [via jogamp] wrote:
> Sorry I use the latest aggregated build which does not contain this fix. I use
> open source Xorg driver for my ATI Radeon 9250 Pro, I have no other choice as
> the proprietary driver is no more provided with my distro (Mageia Linux 2).
> Julien Gouesse

ok, then it should be fixed w/ the latest build / commit.

~Sven