JDK-4990379 : timer functions return JVMTI_ERROR_UNATTACHED_THREAD while heap
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2004-02-06
  • Updated: 2004-03-16
  • Resolved: 2004-02-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
5.0 b39Fixed
Related Reports
Relates :  
JDK-4921421 - JVMTI GC events don't allow to call raw monitor/memory management
Description

Name: dkR10014			Date: 02/06/2004


--------------------------------------
Tests       : nsk/jvmti/IterateOverHeap/iterheap007
              nsk/jvmti/IterateOverInstancesOfClass/iterinstcls007
              nsk/jvmti/IterateOverReachableObjects/iterreachobj005
              nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj005
VM          : ClientVM, ServerVM
Mode        : all
Platform    : generic
OS          : generic
JDK         : 1.5.0 b36
----------------------------------------

The tests fail reporting that JVMTI_ERROR_UNATTACHED_THREAD is
returned when GetCurrentThreadCpuTimerInfo or GetCurrentThreadCpuTime
are invoked in callbacks of Heap iteration functions.

This contradicts to the spec of following timer functions
   GetCurrentThreadCpuTimerInfo
   GetCurrentThreadCpuTime
   GetTimerInfo
   GetTime
which says: 
   This function may be called from the callbacks to the Heap
   iteration functions, or from the event handles for the
   GarbageCollectionStart, GarbageCollectionFinish, and
   ObjectFree events.

Steps to reproduce a failure of nsk/jvmti/IterateOverHeap/iterheap007:

  cd /net/jano.sfbay/export/disk20/GammaBase/Bugs/<this bug number>
  sh build.sh $JAVA_HOME  [-g] [-d64]
  sh run.sh $JAVA_HOME [-g] [-v] [JAVA_OPTS]
where
    -d64   - build for 64-bit solaris-sparcv9
    -g     - build for or run with java_g binaries
    -v     - run in verbose mode
    
Here is test output on Solaris:
-------------------------------------------------------------------------------
$ sh run.sh $JAVA_HOME -v
Run: nsk/jvmti/IterateOverHeap/iterheap007
- iterheap007.c, 105: Wait for debugee start
- iterheap007.c, 110: Calling IterateOverHeap with filter
JVMTI_HEAP_OBJECT_EITHER
# ERROR: iterheap007.c, 31: NSK_CPP_STUB2(GetCurrentThreadCpuTimerInfo,
st_jvmti, &timer_info1 )
#   jvmti error: code=115, name=JVMTI_ERROR_UNATTACHED_THREAD
# ERROR: iterheap007.c, 36: GetCurrentThreadCpuTimerInfo returned zero in
jvmtiTimerInfo.max_value
# ERROR: iterheap007.c, 53: NSK_CPP_STUB2(GetCurrentThreadCpuTime, st_jvmti,
&nanos )
#   jvmti error: code=115, name=JVMTI_ERROR_UNATTACHED_THREAD
# ERROR: iterheap007.c, 57: GetCurrentThreadCpuTime returned zero
# ERROR: iterheap007.c, 72: GetTimerInfo returned negative value in
jvmtiTimerInfo.max_value
- iterheap007.c, 123: Let debugee to finish
Java exit code: 97
-------------------------------------------------------------------------------

The tests will be available in next r27 release of testbase.

======================================================================

Name: dkR10014			Date: 02/15/2004


The test
  nsk/jvmti/scenarios/allocation/AP10/ap10t001
fails due to this bug too.

======================================================================
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta2 FIXED IN: tiger-beta2 INTEGRATED IN: tiger-b39 tiger-beta2 VERIFIED IN: tiger-beta2
14-06-2004
EVALUATION There is a general bug in the wrapper generation whereby functions that are callback safe but can only be called in the live phase result in code that checks that the thread is a java thread - at this time this only impacts GetCurrentThreadCputime and GetCurrentThreadCpuTimerInfo. That said we need to review if it's appropriate for GetCurrentThreadCpuTime calls to be callback safe - the reason is that the heap iteration callbacks may, in some implementations, be called from a different thread than the thread that called the heap iteration function. As a result this may actually require a spec clarification to eliminate the GetCurrentThreadCpu* functions from the list of functions that may be called from the heap iteration callbacks. ###@###.### 2004-02-09 Fixed for b39. ###@###.### 2004-02-11
09-02-2004