This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Null pointer to tls_t structure


I noticed this when debugging the GTK peer problem.  There is a
theoretical problem that a finalizer might access a TLS structure
that has been deallocated.

Andrew.


2008-11-10  Andrew Haley  <aph@redhat.com>

        * java/lang/natThreadLocal.cc (java::lang::ThreadLocal::finalize):
        Null pointer to tls_t structure.

Index: java/lang/natThreadLocal.cc
===================================================================
--- java/lang/natThreadLocal.cc (revision 141575)
+++ java/lang/natThreadLocal.cc (working copy)
@@ -58,7 +58,7 @@
    ThreadLocal is collected, we delete the key.

    This scheme is biased towards efficiency when get() is called much
-   more frequently than set().  It is slightly internaler than the
+   more frequently than set().  It is slightly slower than the
    all-Java solution using the underlying map in the set() case.
    However, get() is very much more frequently invoked than set().

@@ -131,6 +131,7 @@
   if (TLSPointer != NULL)
     {
       tls_t* tls = (tls_t*)TLSPointer;
+      TLSPointer = NULL;
       pthread_key_delete (tls->key);
       _Jv_Free (tls);
     }
z


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]