Upstream? Tracker: http://bugzilla.gnome.org/show_bug.cgi?id=331052

This code happened when we added the splashcreen. This code (though correct from
a GTK usage standpoint)


WindowManager.theManager.splashScreen.showAll();
Timer timer = new Timer(2000, new Fireable() {
public boolean fire() {                                  
WindowManager.theManager.splashScreen.hideAll();                               
      WindowManager.theManager.mainWindow.showAll();
return false;
}

Causes the following GDB bt during GC of that Timer object

Program received signal SIGSEGV, Segmentation fault.
0x02700576 in _Jv_JNI_NewWeakGlobalRef () from /usr/lib/libgcj.so.6
(gdb) bt
#0  0x02700576 in _Jv_JNI_NewWeakGlobalRef () from /usr/lib/libgcj.so.6
#1  0x00701a07 in cleanup (env=0x898a580, obj=0x74add20)
    at /usr/src/debug/libgtk-java-2.8.3/src/jni/org_gnu_glib_Timer.c:26
#2  0x00701b4a in Java_org_gnu_glib_Timer_stop_1timer (env=0x898a580,
    obj=0x74add20, handle=-1)
    at /usr/src/debug/libgtk-java-2.8.3/src/jni/org_gnu_glib_Timer.c:86
#3  0x05dbbb8a in org.gnu.glib.Timer.stop_timer(int) (this=0x74add20,
    handle=-1)
    at /usr/src/debug/libgtk-java-2.8.3/src/java/org/gnu/glib/Timer.java:116
#4  0x05dbbbee in org.gnu.glib.Timer.stop() (this=0x74add20)
    at /usr/src/debug/libgtk-java-2.8.3/src/java/org/gnu/glib/Timer.java:109
#5  0x05dbbc33 in org.gnu.glib.Timer.finalize() (this=0x74add20)
    at /usr/src/debug/libgtk-java-2.8.3/src/java/org/gnu/glib/Timer.java:117
#6  0x0272d745 in _Jv_FinalizeObject () from /usr/lib/libgcj.so.6
#7  0x02743a8b in _Jv_AllocRawObj () from /usr/lib/libgcj.so.6
#8  0x02aa2265 in GC_invoke_finalizers () from /usr/lib/libgcj.so.6
#9  0x02743ae9 in _Jv_RunFinalizers () from /usr/lib/libgcj.so.6
#10 0x02722a5c in gnu::gcj::runtime::FinalizerThread::run ()
   from /usr/lib/libgcj.so.6
#11 0x02732eef in _Jv_ThreadRun () from /usr/lib/libgcj.so.6
#12 0x027453ca in _Jv_ThreadUnRegister () from /usr/lib/libgcj.so.6
#13 0x02aac793 in GC_start_routine () from /usr/lib/libgcj.so.6
#14 0x00c38341 in start_thread () from /lib/tls/libpthread.so.0 

However replace with this code, and Frysk runs fine:


WindowManager.theManager.splashScreen.showAll();
TimerEvent timerEvent = new TimerEvent(0, 5000){
public void execute() {                                       
WindowManager.theManager.splashScreen.hideAll();                               
        WindowManager.theManager.mainWindow.showAll();                         
              Manager.eventLoop.remove(this);
}
};

                        Manager.eventLoop.add (timerEvent);
                }
        });


//      CustomEvents.addEvent(new Runnable() {
//              public void run() {
//                      WindowManager.theManager.splashScreen.showAll();
//                      Timer timer = new Timer(2000, new Fireable() {
//                              public boolean fire() {
//                                     
WindowManager.theManager.splashScreen.hideAll();
//                                     
WindowManager.theManager.mainWindow.showAll();
//                                      return false;
//                              }
//                      });
//                      timer.start();
//              }
//      });

We avoided the issue by using this code in the RHEL4-U3 cut. This avoids use of
the troublesome glib timers. However, this is not a fix but a workaround, and we
should track upstream.

        CustomEvents.addEvent(new Runnable() {
                public void run() {
                        WindowManager.theManager.splashScreen.showAll();
                }
        });

        TimerEvent timerEvent = new TimerEvent(0, 5000){
                public void execute() {
                        CustomEvents.addEvent(new Runnable() {
                                public void run() {                            
           WindowManager.theManager.mainWindow.showAll();                      
                WindowManager.theManager.splashScreen.hideAll();
                                }
                        });
                        Manager.eventLoop.remove(this);
                }
        };
        Manager.eventLoop.add (timerEvent);

After further investigation, it seems a double global reference is cleaned:

In the method fire_method_invoker(gpointer data) in the source
libgtk-java-2.8.3/src/jni/org_gnu_glib_Timer.c

There is a bit o code that does

if (keepFiring == JNI_FALSE) {
cleanup(env, obj);


However if you look at the Timer.java source, you will see it has a finalize()
that calls stop() that calls stop_timer()

If you look at that (stop_timer) method in org_gnu_glib_Timer.c you will see
that also calls cleanup. As this is a result of a finalize() it always gets
called. Therefore if the cleanup() gets called in fire_method_invoker() as well,
this call will try to cleanup a null pointer

However, the first conditional cleanup has to be called when an exception is
thrown in that method code as there is a global reference there that will
prevent finalization of the object, so it has to do cleanup. However this
cleanup on exception sets up the sigsegv for the second cleanup on finalize().

Propose we conditional check the state of the global reference, and only clean
if there is a valid reason to do so.

Filed upstream bug and added a patch:
 http://bugzilla.gnome.org/show_bug.cgi?id=334039

Upstream bug fixed
  http://bugzilla.gnome.org/show_bug.cgi?id=334039