-
Enhancement
-
Resolution: Fixed
-
P4
-
hs24
-
b16
-
generic
-
windows
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8007166 | 8 | Zhengyu Gu | P4 | Closed | Fixed | b75 |
| JDK-8017883 | 7u45 | Zhengyu Gu | P4 | Closed | Fixed | b01 |
| JDK-8007584 | 7u40 | Zhengyu Gu | P4 | Closed | Fixed | b13 |
| JDK-8006725 | hs24 | Zhengyu Gu | P4 | Closed | Fixed | b31 |
During a recent discussion about the Full Debug Symbols (FDS) project,
Tom and I noticed that the current version of the decoder on Windows
does not look in the JDK directory that contains a library's .dll for
symbols.
The Windows SymSetSearchPath() API can be used to do this:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms681368%28v=vs.85%29.aspx.
The Windows decoder should add the following directories to the
symbol search path:
$JAVA_HOME/lib
$JAVA_HOME/jre/lib
$JAVA_HOME/jre/bin/client
$JAVA_HOME/jre/bin/server
If it is possible to determine the path the JVM library it
would be better to add that directory rather than assume
that JVM library we are running is either from jre/bin/client
or jre/bin/server.
Tom and I noticed that the current version of the decoder on Windows
does not look in the JDK directory that contains a library's .dll for
symbols.
The Windows SymSetSearchPath() API can be used to do this:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms681368%28v=vs.85%29.aspx.
The Windows decoder should add the following directories to the
symbol search path:
$JAVA_HOME/lib
$JAVA_HOME/jre/lib
$JAVA_HOME/jre/bin/client
$JAVA_HOME/jre/bin/server
If it is possible to determine the path the JVM library it
would be better to add that directory rather than assume
that JVM library we are running is either from jre/bin/client
or jre/bin/server.
- backported by
-
JDK-8006725 RFE: Windows decoder should add some std dirs to the symbol search path
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
- relates to
-
-
- Closed
-