Best way to enable java.lang.* classes tracing? #702
Labels
Comments
|
I have been working on this pretty large patch to allow this - #690 It is not completely finished yet, although it does mostly work. You could try doing a custom build from that branch to see if you are able to use it to trace Thanks! |
|
@jbachorik, will do. |
|
Hi @smagellan - were you able to do what you wanted? I am preparing to merge the PR and it would be helpful to know whether it solved your problem or not. |
|
@jbachorik, no luck at the moment: ~/opt/btrace-jb-improved_linking-pr690/bin/btrace -v 351496 ThreadStart.class: And the java program being instrumented is located here: https://github.com/smagellan/misc-experiments/blob/master/unsorted/src/main/java/smagellan/test/btrace/ThreadSpawner.java ThreadSpawner.javapublic class ThreadSpawner {
public static void main(String[] args) throws InterruptedException {
System.err.println("pid: " + ProcessHandle.current().pid());
for (int i = 0; i < 1000; ++i) {
spawnThread();
Thread.sleep(5 * 1000);
}
}
private static void spawnThread() throws InterruptedException {
Thread t = new Thread( () -> System.err.println("thread started"));
t.setName("testThread");
t.start();
t.join();
}
}The probe comes from the btrace itself (https://github.com/btraceio/btrace/blob/master/btrace-dist/src/main/resources/samples/ThreadStart.java), however D.probe line was commented: //D.probe("jthreadstart", Threads.name(t)); |
|
Hm, this is intriguing. I have used your reproducer and added it as a functional test in this commit. I can see the trace kicking in and correctly printing the expected message, both when running BTrace on JVM startup and when attaching to the target process. I tried Java 8, 17 and 21 and they all do work. What Java version are you using? |
|
Also, running from command line: |
|
Using the compiled version of the trace - |
|
@jbachorik, I use an openjdk-21 from debian testing(https://packages.debian.org/testing/openjdk-21-jdk): I am pretty sure something is misconfigured at my side, need to investigate further |
|
I have found the cause. btrace works as expected if I run the inspected program in a 'vanilla' way (i.e. start from a command line): Thread.{start,interrupt}(system) and spawnThread(userland) were interceptedAnd it mostly works if the ThreadSpawner is launched via IDE (Intellij IDEA in my case). spawnThread(userland) was intercepted. Thread.{start,interrupt}(system) were not interceptedI have checked the command line, the IDE uses a custom javaagent; that might be the source of the interference: N.B.: I have used https://github.com/smagellan/misc-experiments/blob/master/unsorted/src/main/java/smagellan/test/btrace/ThreadSpawner.java + https://github.com/smagellan/misc-experiments/blob/master/unsorted/src/main/java/smagellan/test/btrace/ThreadStartProbe.java this time |
|
Thanks for confirming! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello.
I would like to trace java.lang.Thread.interrupt() callers. Unfortunately, btrace does not allow that at the moment (#685 (comment), https://github.com/btraceio/btrace/blob/develop/btrace-instr/src/main/java/org/openjdk/btrace/instr/ClassFilter.java#L93) due to the invokedynamic "trampolines". @jbachorik, did you have a chance to find the better way to overcome the issue?
The text was updated successfully, but these errors were encountered: