TestLeak crashes due to GC issues

Ulrich Weigand uweigand@de.ibm.com
Sat Nov 27 18:34:00 GMT 2004


Hello,

I'm seeing an occasional crash when executing the TestLeak libjava
test case.  The crash happens when starting a new thread; in the
routine really_start:

static void *
really_start (void *x)
{
  struct starter *info = (struct starter *) x;
  _Jv_ThreadRegister (info->data);

the info->data pointer is corrupted, and thus _Jv_ThreadRegister
crashes.

This pointer was set up from _Jv_ThreadStart:

void
_Jv_ThreadStart (java::lang::Thread *thread, _Jv_Thread_t *data,
                 _Jv_ThreadStartFunc *meth)
{
[...]
  info = (struct starter *) _Jv_AllocBytes (sizeof (struct starter));
  info->method = meth;
  info->data = data;
[...]
  int r = pthread_create (&data->thread, &attr, really_start, (void *) info);

Note how 'info' is allocated as garbage-collectable memory
using _Jv_AllocBytes.


When the crash happens, the info->data member get corrupted
from within the _Jv_NewPrimArray function:

  __JArray *arr =
    (__JArray*) _Jv_AllocPtrFreeObj (size + elsize * count, klass);
  memset((char *)arr + size, 0, elsize * count);

  jsize *lp = const_cast<jsize *> (&arr->length);
  *lp = count;

because the _Jv_AllocPtrFreeObj call returns the same pointer
as the _Jv_AllocBytes call returned.  As arr->length resides
at offset 8, just like info->data does, the final assignment
clobbers the top half of the info->data pointer.


I'm guessing now that a garbage collection run happened to
hit while the creation of the new thread was 'in flight',
and for some reason the memory pointed to by 'info' was
not recognized as in-use.

Now, my first question is, is the garbage collector 
*supposed* to recognize this memory is in use?  There is
no pointer from any Java data structure to this memory;
the only reference at this point is from somewhere inside
libpthread's thread descriptor (which happens to reside
on the thread stack of the not-yet-fully-initialized
new thread).  Should the GC known about this?

If yes, any suggestions why this might not work?
If no, shouldn't _Jv_ThreadStart be changed to use
some other allocation mechanism?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  Linux on zSeries Development
  Ulrich.Weigand@de.ibm.com



More information about the Java mailing list