Nice to know the difference between something that is zero, and
something that has failed. 8-)
...oops, that says INAVLID_LOAD_ADDRESS
..not INVALID, so other that the typo yes it looks good.
---
Kevin
On 13/12/2019 13:02, Fairoz Matte wrote:
Hi Chris,
Thanks for the review,
Please find t
Great! 8-)
On 16/12/2019 15:36, Fairoz Matte wrote:
Oh yes,
Thanks Kevin for the review.
Corrected the same - http://cr.openjdk.java.net/~fmatte/8235637/webrev.02
Thanks,
Fairoz
Hi,
(s11y and runtime opinions both relevant)
A few times in the last month I've really wanted to compare the Events
logged in the hs_err file, and the time of the JVM's crash.
"elapsed time" in hs_err is only accurate to one second, and has been
since before jdk5 was created.
The diff bel
Oops, and with the bug ID in the title and JBS link:
https://bugs.openjdk.java.net/browse/JDK-8240295
On 02/03/2020 10:47, Kevin Walls wrote:
Hi,
(s11y and runtime opinions both relevant)
A few times in the last month I've really wanted to compare the Events
logged in the hs_err file
oment for me, I backported the elapsed time
logging from
6u4 to 5u19 (https://bugs.openjdk.java.net/browse/JDK-6447157) (2007).
(I said before jdk5 was created, I should have said before it was in
mercurial.)
Thanks
Kevin
On 03/03/2020 01:11, David Holmes wrote:
Hi Kevin,
On 2/03/2020 8:48 pm, Ke
hours, elmins, elsecs);
+ st->print_cr(" elapsed time: %d.%06d seconds (%dd %dh %dm %ds)",
eltime, eltimeFraction, eldays, elhours, elmins, elsecs);
}
On 05/03/2020 00:57, David Holmes wrote:
On 4/03/2020 8:44 am, Kevin Walls wrote:
Thanks David -
Yes there are situations whe
Great, thanks David.
On 05/03/2020 10:38, David Holmes wrote:
Thanks Kevin. I think this is the less risky change and achieves the
goal.
David
On 5/03/2020 8:00 pm, Kevin Walls wrote:
Thanks -
I had tried some ideas in the simple fashion, and we can use %06d
formatting OK maybe such
Great, thanks!
On 07/03/2020 07:53, serguei.spit...@oracle.com wrote:
Hi Kevin,
This looks okay to me as well.
Thanks,
Serguei
Hi Yasumasa ,
The changes build OK for me in the latest jdk, and things still work.
I have not yet seen the dwarf usage in action: I've tried a couple of
different systems and so far have not reproduced the problem, i.e.
jstack has not failed on native frames.
I may need more recent basic lib
InNewThread + 0x4d
0x7fa2857a8c49 JLI_Launch + 0x1529
0x55af1b78db1c main + 0x11c
Thanks
Kevin
On 10/03/2020 12:36, Yasumasa Suenaga wrote:
Hi Kevin,
Thanks for your comment!
On 2020/03/10 18:58, Kevin Walls wrote:
Hi Yasumasa ,
The changes build OK for me in the latest jdk, and th
d
DW_CFA_advance_loc4).
Thanks,
Yasumasa
On 2020/03/11 8:53, Kevin Walls wrote:
Hi -
In testing I wasn't seeing any of the Dwarf code triggered.
With LIBSAPROC_DEBUG set I'm getting the "Could not find
executable section in" for lots of / maybe all the libra
Hi Yasumasa,
Oops, didn't catch this - I also had done some manual testing and in
mach5 but clearly not enough.
Generally I think this looks good.
"lastFrame" can mean last as in final, or last as in previous. "last" is
one of those annoying English words. Here it means final, if we get an
.
Thanks,
Serguei
On 3/26/20 10:40, Kevin Walls wrote:
Hi Yasumasa,
Oops, didn't catch this - I also had done some manual testing and
in mach5 but clearly not enough.
Generally I think this looks good.
"lastFrame" can mean last as in final, or last as in previous.
"last&
Hi Coleen and all -
Given the choice I'd ask that we don't remove attach/detach because it
limits the scope of what a clhsdb can do in future. Commands like jstack
are a one-shot operation. A Tool like clhsdb is ideally more flexible
than that.
The SA is (I suggest) "too static" in its "the
Thanks Magnus - I think webrev.03 expanded to change all the imports
will keep us all happy for now,
Thanks
Kevin
Hi Chris,
Yes I think this looks good.
Question: In nearest_symbol, do we need to initialize
lowest_offset_from_sym to something impossibly high, as if it defaults
to zero we never find a better/nearer result?
Thanks
Kevin
On 07/07/2020 06:10, Chris Plummer wrote:
Hello,
Please help revi
good to clean
this up.
I think what is best is to use ptrdiff_t and initialize
lowest_offset_from_sym to -1. I've updated the webrev:
http://cr.openjdk.java.net/~cjplummer/8247515/webrev.01/index.html
thanks,
Chris
On 7/7/20 4:09 AM, Kevin Walls wrote:
Hi Chris,
Yes I think this looks
Hi Chris --
This is a great story/history lesson.
You could if you like, edit those comments in ElfFileParser.java so
"Elf32_Addr" as they will contain either "Elf64_Addr or Elf32_Addr",
similarly Elf64_Off. The other Elf64 fields are the same as the 32 bit
ones.
Yes, the symbol fields are
thers should be updated too.
Although they are the same size, they do have different names. For
example:
/* Type for a 16-bit quantity. */
typedef uint16_t Elf32_Half;
typedef uint16_t Elf64_Half;
thanks,
Chris
On 7/8/20 3:47 AM, Kevin Walls wrote:
Hi Chris --
This is a great story/history lesson
tracks the size of each library.
http://cr.openjdk.java.net/~cjplummer/8247515/webrev.01/src/jdk.hotspot.agent/macosx/native/libsaproc/symtab.c.frames.html
417 if (offset_from_sym >= 0) { // ignore symbols that comes after
"offset"
Replace: comes => come
Ok.
thanks,
Chris
T
;base > addr) {
Yes, > would be better, although this goes away with my fix that
tracks the size of each library.
http://cr.openjdk.java.net/~cjplummer/8247515/webrev.01/src/jdk.hotspot.agent/macosx/native/libsaproc/symtab.c.frames.html
417 if (offset_from_sym >= 0) { // ignore symbols that comes
a
Hi Chris - Yes, that's a good discovery, looks good,
Thanks
Kevin
On 29/07/2020 21:08, Chris Plummer wrote:
Hello,
Please help review the following:
https://bugs.openjdk.java.net/browse/JDK-8250750
http://cr.openjdk.java.net/~cjplummer/8250750/webrev.00/index.html
Details are in the CR desc
Hi Jini,
Looks good to me. It might be a significant increase in size of _some_
core files, but so many core files we see are much larger, in
gigabytes++ of course, so the CDS data size should not be such a
significant increase on (I think) most files.
The flexibiity of always having the CD
? I think it's
hardly needed for debugging purposes. (Perhaps we can also do the
same for the NIO mapped files?)
A opt-flag as suggested by Kevin is a good idea.
Thanks
- Ioi
On 11/9/18 3:29 AM, Kevin Walls wrote:
Hi Jini,
Looks good to me. It might be a significant increase in si
Hi Severin,
Looks good to me.
This could have merited a distinct bug ID, I think you could argue
either way on that, they are clearly strongly related - in 9, this bug
ID creates a new launcher for all SA tools, here in 8 we're creating the
missing launchers, within the existing 8u launcher s
Hi Stefan,
This is great - if I want to try it out, what order do the changes
apply, does the 8218746 webrev apply to create ZExternalBitMap.java and
then the 8218922 webrev?
Thanks
Kevin
On 14/02/2019 17:12, Stefan Karlsson wrote:
Hi again,
I've separated the live regions iteration refac
Great, thanks Stefan, that collection of changes builds for me and I've
seem the histogram from a live process using ZGC, and a core of the
same. Fantastic. 8-)
On 15/02/2019 19:06, Stefan Karlsson wrote:
Hi Kevin,
On 2019-02-15 13:14, Kevin Walls wrote:
Hi Stefan,
This is great
Hi Fairoz -
Looks good to me too.
The " -encoding utf8" in the test might be a leftover from something
else (maybe /timeout=240 also?), you could leave it out but no problem
either way.
Thanks!
Kevin
On 01/07/2019 05:31, Fairoz Matte wrote:
Hi,
Please review a fix that potentially handle
Hi,
jcmd GC.run to invoke GC fails if -XX:+DisableExplicitGC is set: this
seems like a mistake?
This behaviour is obstructive for a live app that _needs_ a GC, and was
started with -XX:+DisableExplicitGC.
DisableExplicitGC to protect from Java code calling System.gc frequently
makes sense,
k
without documenting it.
Thanks
Kevin
On 28/08/2017 16:01, Mikael Gerdin wrote:
Hi Kevin,
On 2017-08-22 16:38, Kevin Walls wrote:
Hi,
jcmd GC.run to invoke GC fails if -XX:+DisableExplicitGC is set: this
seems like a mistake?
This behaviour is obstructive for a live app that _needs_ a GC, and
w
int_cr("Explicit GC is disabled, no GC has been
performed.");
- }
+ Universe::heap()->collect(GCCause::_dcmd_gc_run);
}
void RunFinalizationDCmd::execute(DCmdSource source, TRAPS) {
bash-4.2$
On 29/08/2017 10:14, Kevin Walls wrote:
Hi Mikael, thanks yes, it could be a separ
Thanks Serguei, and Mikael!
On 30/08/2017 00:33, serguei.spit...@oracle.com wrote:
Hi Kevin,
It looks good to me.
Thanks,
Serguei
On 8/29/17 04:41, Kevin Walls wrote:
Hi,
This is a small review request for:
8186902: jcmd GC.run should not be blocked by DisableExplicitGC
https
Hi -
I think the history of post_vm_init_hook_enabled was from the
hotspot-express idea that the JVM and the runtime environment could be
separate. We could release a new JVM and slot it into an existing
JDK/JRE... In practice, the commented future optimisation never
happened, but they've b
Hi,
I'd like a review of a backport of these test changes, into 8u.
webrev:
http://cr.openjdk.java.net/~kevinw/8039995_8061785/webrev.00/
Changes simply hg imported from:
8039995
http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/raw-rev/da92e4c42b24
8061785
http://hg.openjdk.java.net/jdk9/hs-rt/h
Thanks!
On 18/12/2014 08:12, Staffan Larsen wrote:
Looks good!
Thanks,
/Staffan
On 17 dec 2014, at 17:15, KEVIN WALLS wrote:
Hi,
I'd like a review of a backport of these test changes, into 8u.
webrev:
http://cr.openjdk.java.net/~kevinw/8039995_8061785/webrev.00/
Hi,
This is a review request for a change in JVMTI, where we os::free() some
objects where we should delete them. The problem was logged against 7,
though it exists up to the present day, below is a diff in current
latest http://hg.openjdk.java.net/jdk9/hs-rt/hotspot
Testing:
I've used a n
ble, so that we
can get this fix out in the last public JDK 7 release.
Kind Regards
/Mattis
-Original Message-
From: Kevin Walls
Sent: den 15 januari 2015 15:18
To: serviceability-dev@openjdk.java.net
Subject: RFR: 8035938: Memory leak in JvmtiEnv::GetConstantPool
Hi,
This is a rev
--
Subject:Re: RFR: 8035938: Memory leak in JvmtiEnv::GetConstantPool
Date: Fri, 16 Jan 2015 18:28:50 +0000
From: Kevin Walls
Organization: Oracle Corporation
To: daniel.daughe...@oracle.com, Mattis Castegren
CC: serviceability-dev@openjdk.java.net
Thanks Serguei, thanks Dan!
On
Thanks!
On 28/01/2015 17:45, Daniel D. Daugherty wrote:
src/share/vm/prims/jvmtiClassFileReconstituter.hpp
No comments.
Thumbs up.
Dan
On 1/28/15 10:34 AM, Kevin Walls wrote:
Hi,
I'd like a sanity check review for backporting this from latest/9 to
jdk8u. It's changing
Hi Dmitry - like it, and particularly like getting shouldSAAttach() in
both jdk and hotspot. Yes you're very efficient in just reading that
one byte from those one-byte files! 8-)
Sorry one more thing... JMapHeapConfigTest.java throws an exception
when it doesn't think it will have permiss
, Staffan Larsen wrote:
This looks good, except that I agree with Kevin that we should
silently succeed if SA isn’t allowed to attach. Otherwise we will get
lots of failures in the testing. Sorry I missed this in the last
round of internal review.
/Staffan
On 11 feb 2015, at 23:38, Kevin Walls
wrote
Hi,
This is a review request for a way to make the SA tools protect
themselves from infinite loops during initialisation.
Attaching jmap (for example) to a JVM can fail, infinitely writing an
error - and filling a disk if being logged to a file. This reproduces
on a Solaris package based in
for the stride
size, for example. I think it's worth protecting ourselves from that
kind of problem.
Thanks
Kevin
On 03/03/2015 13:51, Mikael Gerdin wrote:
Kevin,
On 2015-03-03 14:15, Kevin Walls wrote:
Hi,
This is a review request for a way to make the SA tools protect
themselves f
Kevin,
The fix looks good for me, but please add a comment explaining the
problem we are solving here.
-Dmitry
On 2015-03-03 16:15, Kevin Walls wrote:
Hi,
This is a review request for a way to make the SA tools protect
themselves from infinite loops during initialisation.
Attaching jmap (for ex
15 12:29, Staffan Larsen wrote:
On 4 mar 2015, at 12:29, Kevin Walls wrote:
Thanks Dmitry -
I will explain the counter's presence where we introduce it:
// Counter to ensure read loops terminate:
private static final int MAX_DUPLICATE_DEFINITIONS = 100;
private static
Sure, I updated the webrev:
http://cr.openjdk.java.net/~kevinw/8073688/webrev.01/
Thanks
Kevin
On 04/03/2015 14:05, Staffan Larsen wrote:
On 4 mar 2015, at 14:07, Kevin Walls wrote:
Hi Staffan --
staticness: I could have argued that either way, it doesn't need to be static.
A s
Thanks!
Hi,
While this is in memory: I'd like to request review for an 8u backport.
The changeset imports cleanly into jdk8u/hs-dev/hotspot
Thanks
Kevin
On 04/03/2015 15:17, Staffan Larsen wrote:
Looks good!
Thanks,
/Staffan
On 4 mar 2015, at 15:14, Kevin Walls wrote:
Sure, I update
|
Hi Cheleswer, I think Martin is suggesting something like:
|
// Use a modest stack size, unless requested otherwise:
long stackSize = Boolean.getBoolean("processReaperUseDefaultStackSize") ? 0 :
32768;
Thread t = new Thread(systemThreadGroup, grimReaper, "process reaper",
stackSize);
|||
If
this issue will be safer at this point of time.
Regards,
Cheleswer
On 1/19/2016 5:40 PM, David Holmes wrote:
On 19/01/2016 9:53 PM, Kevin Walls wrote:
|
Hi Cheleswer, I think Martin is suggesting something like:
|
// Use a modest stack size, unless requested othe
stack frames, and thread locals should not
steal space from that.
The system property introduced in this change is an ugly workaround for that.
On Thu, Feb 18, 2016 at 2:24 AM, Kevin Walls wrote:
Hi Cheleswer,
Looks good to me.
Thanks
Kevin
(Also, as one of the comments was that there may be no
Hi Cheleswer,
Looks good. (While we've discussed it offline I haven't actually
offered a public review).
Just one more thing, and this concerns the original code not the change:
1880 st->print("Warning: Address: 0x%x, Size: %dK,
",p->pr_vaddr, p->pr_size/1024, p->pr_mapname);
W
Hi
I didn't think of %.s when Cheleswer and I discussed this briefly.
I'd like to have suggested that, with the idea that the 2k long thread
name is extreme, and it's so important that we preserve the format of
the output, and keep that closing quote, even if we lost some of the
thread
nd written a test case also for this bug.
Please review the code changes from the below link
http://cr.openjdk.java.net/~csahu/8151442/webrev.01/
Regards,
Cheleswer
-Original Message-
From: Mattis Castegren
Sent: Wednesday, March 30, 2016 10:42 PM
To: Kevin Walls; David Holmes; Daniel
Thanks Cheleswer, looks good to me too, have been over the macros as
much as I can!
Thanks
Kevin
On 03/05/2016 07:34, Cheleswer Sahu wrote:
Hi Gerard,
-Original Message-
From: Gerard Ziemski
Sent: Monday, May 02, 2016 9:07 PM
To: Cheleswer Sahu
Cc: hotspot-runtime-...@openjdk.ja
ebrev link: http://cr.openjdk.java.net/~csahu/8150900/webrev.01/
Regards,
Cheleswer
From: Cheleswer Sahu
Sent: Wednesday, May 11, 2016 2:29 PM
To: Christian Thalinger
Cc: Kevin Walls; Gerard Ziemski; serviceability-dev@openjdk.java.net;
hotspot-runtime-...@openjdk.java.net
Subject: RE: RFR[9
Hi Vladimir - that's great, thanks for letting us know. I'll get it pushed.
Kevin
On 21/06/2016 17:36, Vladimir Kozlov wrote:
This RFE is approved for push.
Thanks,
Vladimir
On 5/24/16 9:46 AM, Kevin Walls wrote:
...although we consider this a fix, more than a feature, and hope
is line in
agent/src/share/classes/sun/jvm/hotspot/memory/SymbolTable.java
symbolTableSize =
db.lookupIntConstant("SymbolTable::symbol_table_size").intValue(); to
use SymbolTableSize.
Then run the nsk.sajdi.testlist tests.
Thanks,
Coleen
On 8/23/2013 5:34 AM, Kevin Walls wrote:
Hi,
If I have my CHECK and THREAD thinking straight, I have a small review
request in gcNotifier, to avoid a crash that came up in testing recently.
The report is a hotspot crash in a test, where there's an exception
pending when calling java_lang_String::create_from_str, which allocates.
W
ION) {
CLEAR_PENDING_EXCEPTION;
}
}
/Staffan
On 5 sep 2013, at 15:12, Kevin Walls wrote:
Hi,
If I have my CHECK and THREAD thinking straight, I have a small review request
in gcNotifier, to avoid a crash that came up in testing recently.
The report is a hotspot crash in a test, where
Changeset: 592520c14121
Author:kevinw
Date: 2013-09-09 10:01 +0100
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/592520c14121
8023478: Test fails with HS crash in GCNotifier.
Reviewed-by: sla
! src/share/vm/services/gcNotifier.cpp
Changeset: c1d7040a1183
Author:sgabdura
Date: 2013-09-18 16:48 +0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c1d7040a1183
8022836: JVM crashes in JVMTIENVBASE::GET_CURRENT_CONTENDED_MONITOR and
GET_OWNED_MONITOR
Summary: Check that the _java_thread parameter is v
get a size
from the customers that
we then adopt metadata heuristics to.
thanks,
Karen
On Aug 23, 2013, at 5:34 AM, Kevin Walls wrote:
Hi,
I'd like to get reviews on this change to make the size of the symbol table
tunable. This can be a performance benefit to some apps, i.e. when t
Changeset: c90e76575b03
Author:kevinw
Date: 2013-10-08 09:33 +0100
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c90e76575b03
8019375: Internal symbol table size should be tunable.
Reviewed-by: coleenp, kamg
! agent/src/share/classes/sun/jvm/hotspot/memory/SymbolTable.
Hi,
Yes the removal of System.exit didn't take the error value into
account. 8010278 removed the System.exit so these Tool classes were
usable by other tools. I suppose we can use it in main() as if we're
there we should be running as a standalone app.
The execute method seems like a nice
net/%7Eallwin/farvidss/8025638/webrev.01/>
/F
On 2013-10-10 16:49, Kevin Walls wrote:
Hi,
Yes the removal of System.exit didn't take the error value into
account. 8010278 removed the System.exit so these Tool classes were
usable by other tools. I suppose we can use it in main() as if w
Changeset: 396564992823
Author:sgabdura
Date: 2013-11-18 08:21 +0100
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/396564992823
8028341: PSR:FUNC: SCOPE PARAMETER MISSING FROM THE -XX:+PRINTFLAGSFINAL
Reviewed-by: dcubed, sla
! src/share/vm/runtime/globals.cpp
Hi,
This problem means you can't use the SA if the target app contains a
symbol which uses a non-ascii character. The SA tool will fail with an
error, the JVM itself and the SA having calculated different hashes for
such Strings.
bug:
https://bugs.openjdk.java.net/browse/JDK-8028623
webrev
ffan
On 3 jan 2014, at 18:42, Kevin Walls wrote:
Hi,
This problem means you can't use the SA if the target app contains a symbol
which uses a non-ascii character. The SA tool will fail with an error, the JVM
itself and the SA having calculated different hashes for such Strin
Thanks - just need that second reviewer then...
On 13/01/14 12:38, Staffan Larsen wrote:
Looks good! Thanks for taking the time to re-write the test in Java.
Thanks,
/Staffan
On 8 jan 2014, at 15:59, Kevin Walls wrote:
Hi Staffan -
http://cr.openjdk.java.net/~kevinw/8028623/webrev.01
Thanks!
On 17/01/14 14:17, Dmitry Samersoff wrote:
Looks good for me.
-Dmitry
On 2014-01-03 21:42, Kevin Walls wrote:
Hi,
This problem means you can't use the SA if the target app contains a
symbol which uses a non-ascii character. The SA tool will fail with an
error, the JVM itsel
Hi,
Can I just get a review of this jtreg tag change in a testcase. The
testcase specifically contains a utf8 character and to make sure it
compiles everywhere we need to specify -encoding on the @compile line,
and then add an @run line:
webrev
http://cr.openjdk.java.net/~kevinw/8032466/web
Thanks Dmitry, Staffan!
On 23/01/14 07:05, Staffan Larsen wrote:
Looks good!
Thanks,
/Staffan
On 22 jan 2014, at 18:43, Kevin Walls wrote:
Hi,
Can I just get a review of this jtreg tag change in a testcase. The testcase
specifically contains a utf8 character and to make sure it compiles
Hi,
Yes, change looks good I think.
(I was just pleasantly surprised that SA_ALTROOT is respected by the
product build where libsaproc_audit does not exist. But libsaproc_open
is the open routine that respects the alt_root, and it needs to get
called by libproc in order to fixup paths for a
:16, Kevin Walls wrote:
Thanks Dmitry, Staffan!
On 23/01/14 07:05, Staffan Larsen wrote:
Looks good!
Thanks,
/Staffan
On 22 jan 2014, at 18:43, Kevin Walls wrote:
Hi,
Can I just get a review of this jtreg tag change in a testcase. The
testcase specifically contains a utf8 character and to ma
Hi Dmitry,
Looks good, if you're still needing comments.
Always amazing what a good load of nightly testing can find!
Regards
Kevin
On 05/03/14 20:29, Dmitry Samersoff wrote:
Serguei,
Thank you for the review. You are the first reviewer.
-Dmitry
On 2014-03-06 00:25, serguei.spit...@oracle
Hi,
I'd like to get a review of this test change. It assumed that jmap
would have permission to run on a process that the test itself created,
but this is not necessarily the case.
Here I'm considering it OK to skip (pass) the test where jmap fails to
attach. The test itself was not platf
Hi - any comments? 8-)
On 12/05/14 16:02, Kevin Walls wrote:
Hi,
I'd like to get a review of this test change. It assumed that jmap
would have permission to run on a process that the test itself
created, but this is not necessarily the case.
Here I'm considering it OK to skip
moment I'll wait on that other information for whether this
needs to be fixed in the test...
Thanks!
Kevin
On 23/05/14 12:00, Peter Allwin wrote:
Looks good to me!
Thanks for looking at this Kevin,
/peter
On 20 May 2014, at 13:14, Kevin Walls wrote:
Hi - any comments? 8-)
On 12/05/14
Hi - I think this is too late, but just a note that I'd started a review
request on a version of that test which would fail gracefully (pass) if
it wasn't able to use jmap to attach.
But I left that change (bug 8039995, on this alias) pending, waiting to
find out if it was irrelevant - i.e.
Hi,
May I get a review of this little change:
pstack can crash on a Java core, where the core is transported from one
machine to another, and they have different JDKs but in the same
directory location. So pstack does find libjvm etc, and does find
libjvm_db.so (but clearly symbols are not g
Hi,
Looks good to me,
Regards
Kevin
On 18/07/14 12:44, Jaroslav Bachorik wrote:
Please, review the following fix
Issue : https://bugs.openjdk.java.net/browse/JDK-8035829
Webrev: http://cr.openjdk.java.net/~jbachorik/8035829/webrev.00
This issue has been identified by Parfait static code anal
Thanks Serguei, and thanks Sundar,
--
Kevin
On 18/07/14 23:22, serguei.spit...@oracle.com wrote:
Hi Kevin,
It looks good.
Thank you fixing it!
Thanks,
Serguei
On 7/18/14 5:02 AM, Kevin Walls wrote:
Hi,
May I get a review of this little change:
pstack can crash on a Java core, where the
ake sense to me
to do the fix below, including backporting to places where jmap -F still
works.
webrev
http://cr.openjdk.java.net/~kevinw/8039995/webrev.01/
bug
https://bugs.openjdk.java.net/browse/JDK-8039995
Thanks
Kevin
On 24/05/2014 19:25, Kevin Walls wrote:
Thanks Peter, and than
...and an update to the webrev in the same place that also checks the
SELinux deny_ptrace flag, another reason you can get a permission denied
error and fail the test.
http://cr.openjdk.java.net/~kevinw/8039995/webrev.01/
Thanks
Kevin
On 20/11/2014 18:38, KEVIN WALLS wrote:
Hi,
I&#
Thanks Dmitry and Peter!
On 03/12/2014 11:39, Dmitry Samersoff wrote:
Kevin,
Looks good for me!
-Dmitry
On 2014-11-26 16:53, KEVIN WALLS wrote:
...and an update to the webrev in the same place that also checks the
SELinux deny_ptrace flag, another reason you can get a permission denied
possible to
run the tests as a regular user even if you have done 1-3 above. That would be
a shame, but perhaps cannot be avoided given the complexity involved.
/Staffan
On 26 nov 2014, at 14:53, KEVIN WALLS wrote:
...and an update to the webrev in the same place that also checks the SELin
Thanks!
On 03/12/2014 19:50, Staffan Larsen wrote:
I agree. Go ahead with this and hopefully we can revisit it later.
Thanks,
/Staffan
On 3 dec 2014, at 17:17, KEVIN WALLS wrote:
Thanks Staffan -
Yes, I've updated it to be simply canAttachOSX(). Seems likely we should go
ahead with
Hi,
This is a review request for a changing a couple of characters in a
test. It's the same test I just changed with another review, I kept it
separate so as to complicate the review already in progress (it had gone
on long enough..).
The test contains an embedded utf8 character, to test a
Thanks both of you!
On Wed, 3 Feb 2021 22:17:16 GMT, Chris Plummer wrote:
>> We could see NPE on `LinuxCDebugger::loadObjectContainingPC` which is used
>> mainly by the clhsdb `findpc` command. (See
>> [JDK-8248876](https://bugs.openjdk.java.net/browse/JDK-8248876) for more
>> details)
>>
>> It is caused by PIE
On Tue, 2 Feb 2021 23:37:21 GMT, Yasumasa Suenaga wrote:
> We could see NPE on `LinuxCDebugger::loadObjectContainingPC` which is used
> mainly by the clhsdb `findpc` command. (See
> [JDK-8248876](https://bugs.openjdk.java.net/browse/JDK-8248876) for more
> details)
>
> It is caused by PIE exe
On Sun, 7 Feb 2021 02:21:47 GMT, Yasumasa Suenaga wrote:
>> Looks good, I made a suggestions elsewhere in the PR about the comments at
>> line 510...
>
> @kevinjwalls Thank you for the comment!
>
>> I found the "svr4_exec_displacement() in GDB" more confusing than
>> informative, maybe this is
On Tue, 9 Feb 2021 07:35:46 GMT, Yasumasa Suenaga wrote:
>> Oops, I didn't mean to suggest the comment should go entirely. It's
>> actually very useful to say something here, as the way we use the dynamic
>> field, setting it then fixing it up.
>> Is it possible to re-add the comment in a new
On Tue, 9 Feb 2021 17:57:42 GMT, Serguei Spitsyn wrote:
>> I removed the comment about load address of executable in
>> [JDK-8248876](https://bugs.openjdk.java.net/browse/JDK-8248876) (#2366), but
>> it contained useful information for maintenance.
>>
>> So I re-add them, and add comment for t
On Tue, 9 Feb 2021 12:22:00 GMT, Yasumasa Suenaga wrote:
> I removed the comment about load address of executable in
> [JDK-8248876](https://bugs.openjdk.java.net/browse/JDK-8248876) (#2366), but
> it contained useful information for maintenance.
>
> So I re-add them, and add comment for the c
On Sun, 17 Jan 2021 03:57:59 GMT, Chris Plummer wrote:
> See the bug for most details. A few notes here about some implementation
> details:
>
> In the `PointerLocation` class, I added more consistency w.r.t. whether or
> not a newline is printed. It used to for some address types, but not oth
On Wed, 10 Feb 2021 21:12:19 GMT, Chris Plummer wrote:
>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PointerLocation.java
>> line 247:
>>
>>> 245:stackThread.getStackBase(),
>>> stackThread.lastSPDbg(),
>>> 246:
>>> stackThread
On Thu, 11 Feb 2021 23:52:58 GMT, Chris Plummer wrote:
>> See the bug for most details. A few notes here about some implementation
>> details:
>>
>> In the `PointerLocation` class, I added more consistency w.r.t. whether or
>> not a newline is printed. It used to for some address types, but no
On Sat, 13 Feb 2021 19:05:17 GMT, Chris Plummer wrote:
> See bug description for details. The fix is simple and just a matter of
> moving some code to avoid incorrectly thinking an address is in a .so when it
> is in some other area of VM memory that occurs just after the last .so.
Looks good.
1 - 100 of 373 matches
Mail list logo
