Andrew John Hughes writes: > On Monday 08 October 2007 16:58:57 Andrew John Hughes wrote: > > On Thursday 27 September 2007 14:24:50 Ian Rogers wrote: > > > Hi, > > > > > > this patch removes a call to atexit from GtkToolkit. The comment didn't > > > give sufficient detail as to why the atexit call was necessary and the > > > failure I witnessed in the Jikes RVM was as follows: > > > > > > 1) VM runs some AWT code that causes the atexit routine in GtkToolkit to > > > be registered > > > 2) VM shuts down, stopping all of its services (GC...) > > > 3) VM calls exit that calls atexit routines > > > 4) gdk_threads_enter is called via atexit, this then calls JNI monitor > > > enter in the shutdown VM > > > > > > the shutdown VM can't handle the JNI call and locks up. There is an > > > assumption in the Jikes RVM that atexit routines won't exist that call > > > JNI functions.
I can't see that an atexit routine is calling a JNI function. > > > Thanks, > > > Ian > > > > Ping! Any replies? > > Committed. > > 2007-10-12 Ian Rogers <[EMAIL PROTECTED]> > > PR classpath/33746: > * native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkToolkit.c: > Remove atexit call that makes JikesRVM deadlock. It seems to me like this is probably a bug in JikesRVM. Nevertheless, I have seen other bugs thaht cause a deadlock in the same code. I have to presume that there is some very good reason why we don't want queued calls to be sent to GTK/GDK while we're shutting down. Andrew.
