Hello!
The webrev including the check for the "|" at the beginning of the
core_pattern file is at:
http://cr.openjdk.java.net/~jgeorge/8174994/webrev.01/
This webrev also includes a fix for a latent bug on MacOSX, where
corefile debugging was failing due to SA trying to read in the incorrect
mangled symbol name for "Arguments::SharedArchivePath". Clang seems to
have prefixed an extra '_' to change the mangled name from
'_ZN9Arguments17SharedArchivePathE' to
'__ZN9Arguments17SharedArchivePathE' for MachO files. This fix for this
is in src/jdk.hotspot.agent/macosx/native/libsaproc/ps_core.c.
The difference between the earlier patch and this one can be seen at:
http://cr.openjdk.java.net/~jgeorge/8174994/differential.patch
Thank you,
Jini.
On 4/18/2018 10:37 PM, Jini George wrote:
I agree with the need of testing as much as we can. I could do something
on the lines of how other debuggers like LLDB test: if we can't find the
core file location, check for "|" at the beginning of a line in the
/proc/sys/kernel/core_pattern file -- and fail with a message stating
that the system is using a crash reporting tool.
Thank you,
Jini.
On 4/18/2018 12:40 PM, David Holmes wrote:
My 2c ...
We have to have tests that can test core file attaching capability -
else we don't know it works. So we have to try and generate a core file.
But, we have to expect that in many cases no core file will be
generated even if the hs-err file claims it was. For example my
primary local testing system never generates core files even though it
claims to:
# Core dump will be written. Default location: Core dumps may be
processed with "/usr/share/apport/apport %p %s %c" (or dumping to /
export/users/dh198349/valhalla/repos/valhalla-dev/open/test/jdk/core.29848)
apport isn't even installed, even though core_pattern lists it.
Cheers,
David
On 18/04/2018 4:36 PM, Yasumasa Suenaga wrote:
2018-04-18 15:05 GMT+09:00 Jini George <jini.geo...@oracle.com>:
Thank you very much, Yasumasa, for pointing this out. You are right
-- this
would fail in the Linux systems if systemd-coredump is enabled.
I plan to file an enhancement request to address this issue (wrt
systemd-coredump) separately since this would apply to other coredump
generating test cases also like:
test/hotspot/jtreg/compiler/ciReplay/TestSAServer.java.
I agree with you, but...
From what i can gather, i think we might be able to at least partially
address this by using
coredumptl -o <desired_core_path> dump <pid of the crashed process>
in the test cases, provided the kernel.core_pattern variable is not
set to
"|/bin/false".
Let me know if you are not OK with this.
IMHO it is not good.
Some Linux distros use other coredump collector. For example, RHEL 6
uses ABRT, Ubuntu uses Apport, Fedora uses systemd-coredump.
Hence I think we should disable all tests which requires core images
for Linux like a Windows platform.
Thanks,
Yasumasa
Thank you,
Jini.
On 4/14/2018 7:39 PM, Yasumasa Suenaga wrote:
Hi Jini,
ClhsdbCDSCore.java:
Can this test work on modern Linux?
AFAIK modern Linux contains systemd-coredump to gather core
images. So
I concern ClhsdbCDSCore.java fails in the future.
Thanks,
Yasumasa
On 2018/04/12 13:21, Jini George wrote:
Ping: Gentle reminder !
Thanks,
Jini.
On 4/6/2018 9:51 PM, Jini George wrote:
Hello!
Requesting reviews for:
https://bugs.openjdk.java.net/browse/JDK-8174994
Webrev: http://cr.openjdk.java.net/~jgeorge/8174994/webrev.00/
While trying to identify the type given an address, a
WrongTypeException
was getting thrown with various clhsdb commands (like printmdo,
jstack,
etc). This was since SA tries to map an address to a hotspot C++
type by
comparing the vtable address to the vtable address values of known
types. With CDS, since the vtables are copied over for the Metadata
classes, the vtable addresses themselves don't match (though, of
course,
the contents will), and SA errors out.
The fix has been implemented by making changes to read in the md
region
(consisting of the c++ vtables) of the CDS archive in SA, and
mapping
the vtable addresses to the corresponding metadata type
(ConstantPool,
InstanceKlass, InstanceClassLoaderKlass, InstanceMirrorKlass,
InstanceRefKlass, Method, ObjArrayKlass, TypeArrayKlass).
For corefiles, an additional modification has been done to have the
replicated FileMapHeader structure (from
src/hotspot/share/memory/filemap.hpp, which is replicated in SA in
ps_core.c), to be in sync with the corresponding definition in
src/hotspot/share/memory/filemap.hpp.
Test cases to test both live and corefile debugging are being
added with
this. These and other SA tests pass on Mach5.
Thanks,
Jini.
