JDK-4302538 : MethodEntryEvent.location() is not returning null for native method
  • Type: Bug
  • Component: vm-legacy
  • Sub-Component: jvmdi
  • Affected Version: 1.3.0
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2000-01-04
  • Updated: 2000-01-12
  • Resolved: 2000-01-12
Related Reports
Duplicate :  
Description
MethodEntryEvent.location() is not returning null for native method,
 but the Method.location() returns null.

 the location() method in these interfaces(MethodEntryEvent&Method)
 are from Locatable, which is supposed to return null location
 for a nativeMethod.

Tested in windows-NT,JDK1.3.0.R

Steps to reproduce the bug
---------------------------
1)Set path to  JDK1.3.0.R(in Windows platform)
2)Compile the attached files with -g option
3)Start the targetVM with the command
java -Xdebug -Xnoagent
-Xrunjdwp:transport="dt_socket",server=y,suspend=y,address=5670
HelloWorld
4)Start the debugger with the command
java StackFrameTest


Attachments: in evaluate.jar
 --------------------------
 1. JDIScaffold.java
 2. VMConnection.java
 3. StackFrameTest.java
 4. HelloWorld.java
 5. HelloWorldImp.c(used VC++5,to generate library file)


------------------------

evaluate.jar is attached.
Follow the above steps, you can reproduce the problem.

Here is the NT result,
---------------------
 vm is com.sun.tools.jdi.VirtualMachineImpl@64457d
 got vm
JVM version:1.3.0
JDI version: 1.3
JVM description: Java Debug Interface (Reference Implementation) version 1.3 
Java Debug Wire Protocol (Reference Implementation) version 1.0
JVM Debug Interface version 1.0
JVM version 1.3.0 (Java HotSpot(TM) Client VM, interpreted mode)
methodEntryRequest........com.sun.tools.jdi.EventRequestManagerImpl$MethodEntryRequestImpl@45c3ac
###@###.###layHelloWorld()+0 in thread main
Location from METHOD ............null
Location from EVENT ............HelloWorld.displayHelloWorld()+0




Comments
EVALUATION A) I think I'm doing something wrong, because I can't get this code to do anything (except hang). I'm compiling everything $ ./pbk-build.ksh + which java D:/JDK-1.3.0-R/bin/java.exe + javac -g -classpath .;D:/JDK-1.3.0-R/lib/tools.jar JDIScaffold.java + javac -g -classpath .;D:/JDK-1.3.0-R/lib/tools.jar VMConnection.java + javac -g -classpath .;D:/JDK-1.3.0-R/lib/tools.jar StackFrameTest.java + javac -g HelloWorld.java + javah HelloWorld + backslash D:/JDK-1.3.0-R/include + backslash D:/JDK-1.3.0-R/include/win32 + cl /g /ID:\JDK-1.3.0-R\include /ID:\JDK-1.3.0-R\include\win32 HelloWorldImp.c /LD Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86 Copyright (C) Microsoft Corp 1984-1998. All rights reserved. Command line warning D4002 : ignoring unknown option '/g' HelloWorldImp.c Microsoft (R) Incremental Linker Version 6.00.8447 Copyright (C) Microsoft Corp 1992-1998. All rights reserved. /out:HelloWorldImp.dll /dll /implib:HelloWorldImp.lib HelloWorldImp.obj Creating library HelloWorldImp.lib and object HelloWorldImp.exp and I'm running the debuggee $ ./pbk-debuggee + which java D:/JDK-1.3.0-R-classic/bin/java.exe + java -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5670 HelloWorld but when I start the debugger, not that much happens $ ./pbk-debugger + which java D:/JDK-1.3.0-R-classic/bin/java.exe + java -classpath .;D:/JDK-1.3.0-R-classic/lib/tools.jar StackFrameTest vm is com.sun.tools.jdi.VirtualMachineImpl@fe91ef53 got vm JVM version:1.3.0 JDI version: 1.3 JVM description: Java Debug Interface (Reference Implementation) version 1.3 Java Debug Wire Protocol (Reference Implementation) version 1.0 JVM Debug Interface version 1.0 JVM version 1.3.0 (Classic VM, native threads, nojit) In particular I don't get any error messages or anything. Note that the runs above were with the classic VM, which I enforce by deleting the jre/bin/hotspot directory from D:/JDK-1.3.0-R-classic. So, I'll mark the bug as incomplete until someone can tell me how to make it fail. The ksh scripts I'm using are in /net/sqesvr/vsn/GammaBase/Bugs/4302538/. If someone wants to make those work, that would be great. B) Is this a JVMDI implementation bug? It looks like if you ask for the frame location for a native frame you should get a JVMDI_ERROR_OPAQUE_FRAME result. The agent should turn that into a null MethoEntryEvent.location if it wants. peter.kessler@Eng 2000-01-05 This is, in fact, not a JVMDI bug. It was classified as a JVMDI bug because the behavior is different with the classic VM. However, there is another bug that causes that difference in behavior. The problem with Method.location() for native and abstract methods is a known one. See bug 4252790. gordon.hirsch@eng 2000-01-11
11-01-2000