-
Bug
-
Resolution: Fixed
-
P2
-
1.1
-
b01
-
generic
-
generic
-
Not verified
> We think we found a problem in the JVM where memory gets allocated once but
> deallocated twice. The problem showed up when we ran some of the JCK
> vm.classfmt.classfile tests.
>
> The problem is in classloader.c. Memory for cbConstantPool(cb) gets allocated
> once, and deallocated twice.
>
>
> THE ALLOCATION
> LoadClassFromFile() calls
> createInternalClass() calls
> createInternalClass0() calls
> LoadConstantPool()
> /* allocate constant_pool memory from 'context' heap */
> constant_pool = (cp_item_type *)
> allocNBytes(context, nconstants * sizeof(cp_item_type));
> cbConstantPool(cb) = constant_pool;
>
>
> THE FIRST DEALLOCATION
> createInternalClass() calls freeBuffers if it is longjmp-ed to
> as a result of an error being detected:
> if (setjmp(context->jump_buffer)) {
> /* We've gotten an error of some sort */
> freeBuffers(context);
> return FALSE;
> }
>
> freeBuffers() deletes all the 'context' memory, including the
> memory allocated by LoadConstantPool() for cbConstantPool(cb)
>
>
> THE SECOND (AND ERRONEOUS) DEALLOCATION
> LoadClassFromFile() detects the error returned by createInternalClass()
> It then calls FreeClass() which illegaly frees cbConstantPool(cb)
The above description is based on a 1.1 VM - but this still appears to be
an issue in 1.1.1 even though cbConstantPool(cb) is not assigned a value
until the end of the LoadConstantPool() routine.
> deallocated twice. The problem showed up when we ran some of the JCK
> vm.classfmt.classfile tests.
>
> The problem is in classloader.c. Memory for cbConstantPool(cb) gets allocated
> once, and deallocated twice.
>
>
> THE ALLOCATION
> LoadClassFromFile() calls
> createInternalClass() calls
> createInternalClass0() calls
> LoadConstantPool()
> /* allocate constant_pool memory from 'context' heap */
> constant_pool = (cp_item_type *)
> allocNBytes(context, nconstants * sizeof(cp_item_type));
> cbConstantPool(cb) = constant_pool;
>
>
> THE FIRST DEALLOCATION
> createInternalClass() calls freeBuffers if it is longjmp-ed to
> as a result of an error being detected:
> if (setjmp(context->jump_buffer)) {
> /* We've gotten an error of some sort */
> freeBuffers(context);
> return FALSE;
> }
>
> freeBuffers() deletes all the 'context' memory, including the
> memory allocated by LoadConstantPool() for cbConstantPool(cb)
>
>
> THE SECOND (AND ERRONEOUS) DEALLOCATION
> LoadClassFromFile() detects the error returned by createInternalClass()
> It then calls FreeClass() which illegaly frees cbConstantPool(cb)
The above description is based on a 1.1 VM - but this still appears to be
an issue in 1.1.1 even though cbConstantPool(cb) is not assigned a value
until the end of the LoadConstantPool() routine.