note that for *nix systems that use SIGQUIT as an initiator for attach,
there exists a potential fatal "bug" where (especially a programmatic)
attach attempt may send SIGQUIT before the target/attachee JVM has
initialized such that its signal handlers
are installed.
If the target JVM has not i
I believe you can ignore bucket "zz"
- Larry
On 6/18/25 2:46 PM, Laurence Cable wrote:
On 6/18/25 12:44 PM, Sergey Chernyshev wrote:
Hi Larry,
Thank you for your comments! Yes, it's probably more like base 32 / 5
bits per symbol. The function is actually __user_loca
er into it.
Thanks,
Sergey
Am 18.06.25 um 19:23 schrieb Laurence Cable:
I believe that somewhere in the bowels of MacOS libc there is a
(hopefully public) function that will map a UID to the UUID used to
construct
the per-user directory path from a base 36(?) encoded string thereof,
the leading 2
I believe that somewhere in the bowels of MacOS libc there is a
(hopefully public) function that will map a UID to the UUID used to
construct
the per-user directory path from a base 36(?) encoded string thereof,
the leading 2 characters of which form the "buckets" in /var/folders
and the remaind
https://git.openjdk.org/jdk/pull/25529
On 5/30/25 4:58 AM, Philippe Marschall wrote:
Should I open the PR? I think we're all pretty much in agreement
regarding the fix.
Cheers
Philippe
On 29.05.25 20:59, Laurence Cable wrote:
ignore this... apologies
On 5/29/25 11:51 AM, Laurence
Ive already done it...
On 5/30/25 4:58 AM, Philippe Marschall wrote:
Should I open the PR? I think we're all pretty much in agreement
regarding the fix.
Cheers
Philippe
On 29.05.25 20:59, Laurence Cable wrote:
ignore this... apologies
On 5/29/25 11:51 AM, Laurence Cable wrote:
ignore this... apologies
On 5/29/25 11:51 AM, Laurence Cable wrote:
https://github.com/openjdk/jdk/pull/25526
On 5/29/25 11:05 AM, Kevin Walls wrote:
OK thanks Philippe, and Larry -
I can't provoke a problem as it stands but yes it would be good to
take the recommendation of the API
https://github.com/openjdk/jdk/pull/25526
On 5/29/25 11:05 AM, Kevin Walls wrote:
OK thanks Philippe, and Larry -
I can't provoke a problem as it stands but yes it would be good to
take the recommendation of the API Note, that should keep us
efficient. 8-)
I created a JBS issue: https://bug
actually so did I ...
On 5/29/25 11:05 AM, Kevin Walls wrote:
OK thanks Philippe, and Larry -
I can't provoke a problem as it stands but yes it would be good to
take the recommendation of the API Note, that should keep us
efficient. 8-)
I created a JBS issue: https://bugs.openjdk.org/brows
probably makes sense to fix regardless... my bad
On 5/29/25 3:21 AM, Kevin Walls wrote:
Hi --
Just to be clear, is this an actual persistent leak that we can
observe, or is it that we could close earlier with try-with-resources?
I'm not seeing a leak when calling a line like this over and over
able instead of redefining the
existing one?
e.g: %c
- Larry
----
*From:* Laurence Cable
*Sent:* Thursday, January 30, 2025 9:14:53 AM
*To:* Kemper, William; serviceability-dev; David Holmes;
hotspot-runtime-...@openjdk.or
On 1/29/25 5:56 PM, David Holmes wrote:
Adding back serviceability-dev
David
On 30/01/2025 11:55 am, David Holmes wrote:
Plus one to what Kevin says. The current specified behaviour seems to
me to be what would be generally desired. If there is a desire for a
different kind of timestamp t
On 12/16/24 8:45 AM, Martin Doerr wrote:
On Mon, 16 Dec 2024 16:28:29 GMT, Laurence Cable wrote:
again what's the use case?
Assume a customer uses a tool like the async profiler and causes a JVM crash by
doing that. A supporter looks at the hs_err file and wonders about what might
again what's the use case?
On 12/16/24 6:35 AM, Matthias Baesken wrote:
On Mon, 16 Dec 2024 12:53:52 GMT, Matthias Baesken wrote:
We should output more information about the JVMTI agents in the hserr file.
Matthias Baesken has updated the pull request incrementally with one additional
comm
On 11/12/24 6:21 PM, Serguei Spitsyn wrote:
On Tue, 12 Nov 2024 23:52:35 GMT, Laurence Cable wrote:
t is not feasible to introspect on the target process to determine if
it is a JVM or not, this is the best case not to send SIGQUIT to a
process that is neither catching nor blocking it
I should also note that on other *nix'es (where there is no /proc to
introspect) the default behavior is simply to send the QUIT regardless.
In the case of Linux, this addition obviates the chance of an attach
killing the target should it not be catching QUIT!
On 11/12/24 3:45 PM, Lau
On 11/12/24 3:33 PM, Serguei Spitsyn wrote:
On Thu, 7 Nov 2024 04:48:28 GMT, Serguei Spitsyn wrote:
Larry Cable has updated the pull request incrementally with one additional
commit since the last revision:
JDK-8342449: fixed missing param in throws msg and renamed local var
src/jdk.
fix to 8327114 pushed. https://github.com/openjdk/jdk/pull/21312
On 10/2/24 8:44 AM, Daniel D. Daugherty wrote:
On Tue, 1 Oct 2024 15:38:56 GMT, SendaoYan wrote:
Hi all,
Test `com/sun/tools/attach/PermissionTest.java` fails access denied after
[JDK-8327114](https://bugs.openjdk.org/browse/J
Daniel I plan to push a PR that will fix the attach code later today!
- Larry
On 10/2/24 8:44 AM, Daniel D. Daugherty wrote:
On Tue, 1 Oct 2024 15:38:56 GMT, SendaoYan wrote:
Hi all,
Test `com/sun/tools/attach/PermissionTest.java` fails access denied after
[JDK-8327114](https://bugs.openjd
Severin many many thanks for reviewing this PR it was in danger of being
dropped w/o another reviewer!
Rgds
- Larry
On 9/26/24 1:31 AM, Severin Gehwolf wrote:
On Tue, 2 Jul 2024 11:07:56 GMT, Sebastian Lövdahl wrote:
8327114: Attach in Linux may have wrong behaviour when pid == ns_pid
On 7/17/24 10:03 PM, Thomas Stuefe wrote:
On Thu, 18 Jul 2024 00:45:24 GMT, Leonid Mesnik wrote:
Sonia Zaldana Calles has updated the pull request incrementally with one
additional commit since the last revision:
Updates based on feedback
src/hotspot/share/code/codeCache.cpp line 1791
On 7/12/24 12:06 PM, Ron Pressler wrote:
On 10 Jul 2024, at 16:37, Jaroslav Bachorik wrote:
This may not always be possible. Some systems have rather complex and inlexible
launchers - for example Apache Spark with its clusters, drivers and executors
and automatic distribution of resources
On 7/1/24 5:59 AM, Kevin Walls wrote:
On Mon, 1 Jul 2024 07:19:48 GMT, Sebastian Lövdahl wrote:
8327114: Attach in Linux may have wrong behaviour when pid == ns_pid
(Kubernetes debug container)
Sebastian Lövdahl has updated the pull request incrementally with one
additional commit since
On 6/28/24 8:45 AM, Severin Gehwolf wrote:
On Thu, 27 Jun 2024 18:40:09 GMT, Larry Cable wrote:
Severin Gehwolf has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 17 commits:
- Refactor mount info matching to helper function
-
will do!
On 6/26/24 3:04 AM, Severin Gehwolf wrote:
On Tue, 25 Jun 2024 13:54:46 GMT, Severin Gehwolf wrote:
Please review this enhancement to the container detection code which allows it to
figure out whether the JVM is actually running inside a container (`podman`,
`docker`, `crio`), or w
Forwarded Message
Subject: Re: RFR: 8332124: Jcmd processing should accept the "help" sub
option as command argument [v2]
Date: Tue, 25 Jun 2024 13:30:04 -0700
From: Laurence Cable
To: serviceability-dev@openjdk.org
what about '*jcmd help *&#x
and jcmd already supports "help" w/o a target argument, so this pattern
is a natural extension, and one which other toolsets have adopted!
On 6/25/24 1:28 PM, Laurence Cable wrote:
what about '*jcmd help *'
not a great deal of additional code for the 'help' j
what about '*jcmd help *'
not a great deal of additional code for the 'help' jcmd to delegate to
the target jcmd?
- Larry
On 6/25/24 10:15 AM, Kevin Walls wrote:
On Tue, 25 Jun 2024 13:55:32 GMT, Sonia Zaldana Calles
wrote:
Hi all,
This PR addresses [8332124](https://bugs.openjdk.org/b
On 6/4/24 5:57 AM, Sebastian Lövdahl wrote:
On Tue, 21 May 2024 17:10:15 GMT, Sebastian Lövdahl wrote:
8327114: Attach in Linux may have wrong behaviour when pid == ns_pid
(Kubernetes debug container)
Sebastian Lövdahl has updated the pull request incrementally with two
additional commits
I did some thinking on this issue over the weekend and came up with an
idea that *may* improve the probability of an attach succeeding in the
case that the target has elevated privileges and the jcmd is not in the
same mnt namespace as the target JVM.
basically, the idea is to recurse "up"the
On 5/3/24 10:43 AM, jdoylei wrote:
On Thu, 2 May 2024 10:13:51 GMT, Sebastian Lövdahl wrote:
8327114: Attach in Linux may have wrong behaviour when pid == ns_pid
(Kubernetes debug container)
I think it boils down to the same reason as why the fix for JDK-8226919 was needed in
the first pl
just a thought ... what if the code were to recurse "up" the process
tree if the target JVM had elevated privs (and its /proc/... was not
accessible), in order to find an
ancestor whose /proc was accessible, since the JVM itself does not
modify its pid or mnt namespaces (or capabilities) only an
proc//root is.
/Sebastian
On 2024-05-05 00:06, Laurence Cable wrote:
so I think to summarize the logic we require:
1) if we can determine that the attacher and attachee occupy the same
mnt ns (/proc//ns/mnt == /proc//ns/mnt), return
"/tmp"
2) if they are not in the same mnt ns:
so I think to summarize the logic we require:
1) if we can determine that the attacher and attachee occupy the same
mnt ns (/proc//ns/mnt == /proc//ns/mnt), return "/tmp"
2) if they are not in the same mnt ns:
- test the /proc//root/tmp path for readability, if it
is, return that
- if
I'll ponder ... have a good weekend!
regardless I think the added check for mnt ns comparison "adds value" by
expressing the constraints explicitly vs comparing pid & ns pid
Rgds
- Larry
On 5/3/24 9:45 AM, Sebastian Lövdahl wrote:
On Thu, 2 May 2024 10:13:51 GMT, Sebastian Lövdahl wrote:
diff --git
a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
b/src/jdk.attach/linux/classes/sun/tools/attach/V
irtualMachineImpl.java
index 81d4fd259ed..74bd60c791d 100644
--- a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
+++ b/src/jdk.attach/linux
using pid to namespace comparison is IMO inappropriate/misleading what
is being tested is the sharing of a common mount namespace, therefore
the test should be comparing the "mnt" namespace ids.
Rgds
- Larry
On 5/2/24 3:22 AM, Sebastian Lövdahl wrote:
On Thu, 2 May 2024 10:13:51 GMT, Sebasti
/ns/mnt if the attacher does not
have sufficient privilege to access that due
to attachee capabilities etc then the attach will fail
Rgds
- Larry
/Sebastian
On 2024-05-02 03:43, Laurence Cable wrote:
just to demonstrate:
$ docker run -it --name=js1 openjdk:17.0.1-jdk /bin/jshell
...
$ do
just to demonstrate:
$ docker run -it --name=js1 openjdk:17.0.1-jdk /bin/jshell
...
$ docker run -it --name js2 --pid=container:js1 openjdk:17.0.1 /bin/jshell
$ docker exec -it js1 bash
bash-4.4# ls /tmp/hsperfdata_root
1 26
bash-4.4# readlink /proc/26/ns/pid
pid:[4026532751]
bash-4.4# read
On 5/1/24 2:03 PM, Doyle, James, K wrote:
Hi Sebastian,
I think I can confirm that there is a regression.
Thanks for reproducing the regression, your test makes sense to me, and I think
it is similar to the scenario we have with Kubernetes debug containers
(separate filesystems, but same
On 4/18/24 2:54 AM, Severin Gehwolf wrote:
On Wed, 17 Apr 2024 01:07:04 GMT, Jan Kratochvil
wrote:
IMHO `is_containerized()` is OK to return `false` even when running in a
container but with no limitations set.
The idea here is to use this property to tune OpenJDK for in-container,
spec
On 4/18/24 9:38 AM, Severin Gehwolf wrote:
On Thu, 18 Apr 2024 13:27:38 GMT, Jan Kratochvil
wrote:
Could not we rename `is_containerized()` to `use_container_limit()` ? As that
is the current only purpose of `is_containerized()`.
I'm not sure. There is value to have `is_containerized()`
Hi Maxim, a great idea, the JDK serviceability team here at Oracle would
like to assist you in any way we can.
I think also we should (in the future) consider the format of the error
file and associated jcmd and perhaps render the content
in a format that is better suited to programmatic parsin
Forwarded Message
Subject:RFO: a tool to analyze HotSpot fatal error logs
Date: Thu, 11 Apr 2024 18:05:44 +0400
From: Maxim Kartashev
To: disc...@openjdk.org, hotspot-...@openjdk.org
Hello,
I am writing to inquire about the potential interest of the people
looking at the "attacher" code in jdk.attach it certainly does not
appear to attempt to "attach" via cwd, so I would say that the
"attachee" code to check this is redundant, unless there is a backwards
compatibility/interoperability issue that requires this where
an early JDK "attacher" might a
On 2/5/24 1:56 AM, Kevin Walls wrote:
On Mon, 5 Feb 2024 09:25:24 GMT, Yi Yang wrote:
jcmd VM.debug MyDebugCode.java
Are you thinking to run some Java code in the target JVM?
VM.debug as presented here is all about inspecting JVM state, mostly using
existing mechanisms but which were not
Thanks Marcus!!!
looking forward to it!
- Larry
On 10/15/23 1:28 PM, Marcus Hirt wrote:
Hi all,
Roughly 19 months ago I held an OpenJDK Serviceability Meetup, where a
few people (35 in total) from various companies (Oracle, SAP, Red Hat,
Datadog, Azul, VMware and more) interested in OpenJDK
On 9/28/23 10:38 PM, Alan Bateman wrote:
On 28/09/2023 21:42, daniel.daughe...@oracle.com wrote:
java.lang.instrument is owned by the Serviceability Team so I'm
redirecting this
message to that alias...
This doesn't look like a JDK issue, instead it looks like
|com.github.jelmerk.ObjectS
this is effectively what dynamic agent loading enables, which
https://openjdk.org/jeps/451 proposes to disable.
Rgds
- Larry Cable
On 7/16/23 10:09 PM, David Holmes wrote:
On 17/07/2023 12:21 pm, Yi Yang wrote:
Actually, this is not a very new and strange idea. I often encounter
similar need
I think while this discussion is an interesting one, and clearly one the
elicits strong opinions; I believe that the focus on the proposed change
on dynamic loading of agents has truly been lost therein, further
exchanges have little relevance to the topic of Java serviceability and
the issue a
agree Alan
On 7/14/22 1:27 AM, Alan Bateman wrote:
On Thu, 14 Jul 2022 07:54:56 GMT, xpbob wrote:
Thanks for review. The runtime information is already fetched through the
OperatingSystemMXBean, and I'm wrapped through the interface, keeping only the
configuration data.Such an interface cou
51 matches
Mail list logo
