btraceio / btrace Goto Github PK

[reporter="joachimhskeie", created="Fri, 16 Jul 2010 22:09:05 +0200", resolved="Fri, 30 Jul 2010 09:10:04 +0200"]

Printing aggregations with version 1.2, leads to a StackOverflowException. This is because the methods BTraceUtils.printAggregations calls itself. I added methods to the inner class Aggregations which in turn calls BTraceRuntime. I am pushing the changes, as this is a rather serious bug, but the Javadoc for the Aggreations methods are still missing.

[reporter="joachimhskeie", created="Wed, 27 Jan 2010 17:25:12 +0100", resolved="Fri, 9 Jul 2010 16:18:58 +0200"]

BTraceUtils have heapUsage() and nonHeapUsage() methods. However, I would also like to be able to get the memory usage for the other memory pools like new generation, old generation and the surviorspace as well as the permanent generation.

[reporter="tviessmann", created="Wed, 25 Apr 2012 15:05:31 +0200", resolved="Wed, 9 May 2012 14:09:00 +0200"]

If I run the example AllCalls3.java e.g. on one of the demos such as SwingSet2
I will get this exception:

btrace DEBUG: java.lang.ArrayIndexOutOfBoundsException: 1
java.lang.ArrayIndexOutOfBoundsException: 1
at com.sun.btrace.runtime.Instrumentor$4.injectBtrace(Instrumentor.java:
425)
at com.sun.btrace.runtime.Instrumentor$4.onBeforeCallMethod(Instrumentor
.java:476)
at com.sun.btrace.runtime.MethodCallInstrumentor.visitMethodInsn(MethodC
allInstrumentor.java:58)
at com.sun.btrace.org.objectweb.asm.MethodAdapter.visitMethodInsn(Unknow
n Source)
at com.sun.btrace.org.objectweb.asm.ClassReader.accept(Unknown Source)
at com.sun.btrace.org.objectweb.asm.ClassReader.accept(Unknown Source)
at com.sun.btrace.runtime.InstrumentUtils.accept(InstrumentUtils.java:66
)
at com.sun.btrace.runtime.InstrumentUtils.accept(InstrumentUtils.java:62
)
at com.sun.btrace.agent.Client.instrument(Client.java:374)
at com.sun.btrace.agent.Client.doTransform(Client.java:195)
at com.sun.btrace.agent.Client.transform(Client.java:147)
at sun.instrument.TransformerManager.transform(Unknown Source)
at sun.instrument.InstrumentationImpl.transform(Unknown Source)
at sun.instrument.InstrumentationImpl.retransformClasses0(Native Method)

at sun.instrument.InstrumentationImpl.retransformClasses(Unknown Source)

at com.sun.btrace.agent.Main$4.run(Main.java:438)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source
)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

The issue is due the AnyType [] args
When replaced with other parameters it will work.

[reporter="j.bachorik", created="Wed, 20 Oct 2010 20:41:06 +0200", resolved="Wed, 20 Oct 2010 20:41:49 +0200"]

There is a new version of ASM framework out there. We should use it in BTrace.

[reporter="jbachorik", created="Fri, 27 Aug 2010 08:01:20 +0200", resolved="Mon, 30 Aug 2010 11:27:02 +0200"]

When specifying an invalid regex pattern (eg. "/^(?!(com\\.sun\\.|sun\\.|java\\.|javax
.).*$/" - missing the closing parenthesis) BTrace crashes while trying to instrument the target classes and leaves the BTrace server in the traced application in inconsistent state making it impossible to connect to that application again.

[reporter="j.bachorik", created="Thu, 3 Jul 2014 19:45:19 +0200", resolved="Fri, 4 Jul 2014 18:14:41 +0200"]

A JDK8 only method slipped into BTrace 1.2.5 meaning that BTrace won't run on anything else than JDK8.

[reporter="joachimhskeie", created="Thu, 24 Oct 2013 11:07:13 +0200", resolved="Tue, 3 Dec 2013 10:04:04 +0100"]

When using BTrace 1.2 to monitor applications running in a Tomcat instance, and when Tomcat is set to Hot Deploy (meaning that it will undeploy and redeploy a .WAR-application when the .WAR file change), eventually the JVM runs out of space in the Permanent Generation.

I am assuming this is due to the fact that BTrace re-instruments the classes upon deploy, and that old instrumented classes aren't cleared away fully?

In a moderate-sized Java application running with -XX:MaxPermSize=128m, typically three to four hot deploys cause an OOME in the PermGen space. Increasing the PermSpace, enables more redeploys, but eventually OOME do occur regardless.

I am not sure if this fault lies with BTrace or with Tomcat.

[reporter="jbachorik", created="Wed, 25 Aug 2010 16:36:33 +0200", resolved="Wed, 25 Aug 2010 16:37:15 +0200"]

For the purposes of providing real-time performance metrics to the VisualVM Tracer it became necessary to have the infrastructure for capturing the method runtime metrics in very compact and efficient way.

Currently, an aggregation would be used to obtain such data. The problem is that at least 4 aggregations would be necessary to track invocation count, total time, min and max - this leading to huge performance impact. Not even mentioning that it is impossible to calculate a method self time (time spent within a method minus the time spent in the methods it called).
Because of this a new entity was created - a Profiler. Profiler basically tracks the enter/exit events to a particular code block and assigns the duration to it. It is aware of the call tree so it can calculate the self time as well as not counting the time spent in callees during recursive processing. A profiler can be exposed as a @Property as well as a snapshot can be made and printed via printSnapshot() method.

All the methods related to profiling are placed in BTraceUtils.Profiling namespace.

[reporter="jbachorik", created="Tue, 26 Jan 2010 16:44:53 +0100", resolved="Wed, 17 Feb 2010 13:41:03 +0100"]

For visual tooling it is important to be able to track the class retransformation process - it will enable it to update its UI accordingly to the BTrace engine state and provide the user with visual indication of the behind-the-curtains activity. Otherwise it just seems like the BTrace got stuck after successfully deploying a script.

[reporter="joachimhskeie", created="Sat, 24 Apr 2010 22:00:11 +0200", resolved="Fri, 9 Jul 2010 16:21:38 +0200"]

So that I can build up strings with multiple values without needing to call print() or println() multiple times, like:

append(sb, "[HeapMemory;");
    append(sb, property("btrace.agentname"));
    append(sb, ";");
    append(sb, (max(heapUsage()))); 
    append(sb, ";");
    append(sb, (used(heapUsage()))); 
    append(sb, ";");
    append(sb, (committed(heapUsage()))); 
    append(sb, ";");
    append(sb, (init(heapUsage()))); 
    append(sb, ";");
    append(sb, (timePeriod)); 
    append(sb, "]");
    println(str(sb));

I am including a diff script that implements this functionality (diff from Revisjon 296).

I chose StringBuffer over StringBuilder as StringBuffer is Thread-safe.

Hopefully this can make it into version 1.2.

[reporter="fs5", created="Tue, 25 May 2010 11:56:08 +0200", resolved="Fri, 9 Jul 2010 16:16:46 +0200"]

I am running BTracing in agent-mode:
-javaagent:btrace-agent.jar=noServer=true,debug=true,script=$

{btrace.classfiles}

,scriptOutputFile=$

{basedir}

/out.trace

After the traced program has finished, the java process remains alive. The reason for this is a non daemon-thread created by BTrace

"pool-2-thread-1" prio=6 tid=0x17dc9c00 nid=0xe14 waiting on condition [0x1804f000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x090901f0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1925)
    at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
    at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
    at java.lang.Thread.run(Thread.java:619)

This serves me as a workaround:

    private static final ThreadFactory daemonizedThreadFactory = new ThreadFactory() {
        ThreadFactory delegate = Executors.defaultThreadFactory();
        @Override
        public Thread newThread(Runnable r) {
            Thread result = delegate.newThread(r);
            result.setDaemon(true);
            return result;
        }
    };
    private static final ExecutorService serializedExecutor = Executors.newSingleThreadExecutor(daemonizedThreadFactory);

[reporter="jim.bim", created="Thu, 4 Jul 2013 01:03:49 +0200", resolved="Fri, 13 Sep 2013 08:27:09 +0200"]

When the new btrace is run on 1.6 JVM, it ends up with
java.lang.UnsupportedClassVersionError: com/sun/btrace/client/Main : Unsupported major.minor version 51.0
meaning that the source code has been compiled with Java7 compiler.

When I tried to compile the stuff with 1.6 myself, I noticed one location that will make problems even when compiled with 1.6 classfile compatibility - @SupportedSourceVersion(SourceVersion.RELEASE_7) in Verifier - that's going to crash for sure in runtime.

I wonder if we could
1) Have verifier with Source level 6 annotation, and extend it with Verifier7 with no extra code, but the new @SupportedSourceVersion annotation. Compiler would than instantiate the proper "7" verifier, if available running on 7+, and fall back to 6 if it cannot be loaded.
2) Compile the files with class compatibility for Java 6.
3) Or maybe the JVM-specific Verifier classfile could be generated dynamically? Then the codebase could be compiled with Java 6...

[reporter="joachimhskeie", created="Sat, 29 Jan 2011 21:59:59 +0100", resolved="Sat, 29 Jan 2011 22:02:47 +0100"]

Line 922 of BTraceRuntime called removeLast, while the method signature reads removeFirst. I am fixing this issue and committing to the head branch.

[reporter="herrfluff", created="Fri, 8 Jan 2010 10:35:11 +0100", resolved="Fri, 8 Jan 2010 11:19:34 +0100"]

Original post can be found here.

Description of how to reproduce this issue. Port 1234 is example port and Test.java is example BTrace script.

1. No process is listening on 2020
2. Executed BTrace, "btrace 1234 Test.java" and stopped it with ctrl + c, 1
3. The Java process with the pid 1234 in step 2 is listening on port 2020
4. Executed BTrace again as in step 2 but get the following error: "port 2020 not available. exiting" and BTrace exits

Related to BTRACE-14 - Bind Exception doesn't show up in btrace trace.

[reporter="joachimhskeie", created="Sun, 14 Mar 2010 23:30:40 +0100", resolved="Sat, 24 Apr 2010 19:48:49 +0200"]

When the parameter scriptOutputFile is specified all BTrace output is appended to a single file. It would be nice if this file could be rolled (either time based or triggered with a BTrace Script - or both) and its number incremented. This is both to be able to set up output file deletion (so to not overflow the filesystem with script output, as well as enabling integration with the BTrace agent to a remote application.

As a developer of EurekaJ, I need a consistent feature that will allow integration with the EurekaJ Mangager where BTrace Script output is passed along to the manager application via HTTP, JMS og Webservice calls. (A conceptual drawing of the intended architecture is found at: http://confluence.haagen.name/display/eurekaj/Overall%20Arcitecture).

This issue originated from BTRACE-29 which wont be included in the BTrace source.

This issue can be implemented with something like:

File scriptOutputFile_renameFrom = new File(scriptOutputFile);
File scriptOutputFile_renameTo = new File(scriptOutputFile + ".1");
if (scriptOutputFile_renameFrom.exists()) {

if (scriptOutputFile_renameTo.exists()) {

scriptOutputFile_renameTo.delete();

}

scriptOutputFile_renameFrom.renameTo(scriptOutputFile_renameTo);

}

}

[reporter="joachimhskeie", created="Fri, 16 Jul 2010 15:47:42 +0200", resolved="Wed, 25 Aug 2010 15:56:32 +0200"]

This property would be set by the user via -Dbtrace.agentname=myagent on the commamdline. The property would be used both via the Btrace scripts and to specify the output filename. I will attach one example usage later today.

If btrace.agentname is not specified, Btrace would use a default name, for instance "unknownAgent" or "defaultAgent".

[reporter="joachimhskeie", created="Sat, 28 Aug 2010 17:43:20 +0200", resolved="Sun, 29 Aug 2010 19:22:46 +0200"]

I was trying out the new Profiler options with the following script:

package org.eurekaj.btracers;
import com.sun.btrace.annotations.;

import com.sun.btrace.aggregation.;

import static com.sun.btrace.BTraceUtils.*;

import com.sun.btrace.Profiler;

import java.util.Deque;
@BTrace public class EurekaJProfiler {

@Property(name="eurekaJProfiler") private static Profiler eurekaJProfiler = Profiling.newProfiler();
    @OnMethod(
clazz=<span class="code-quote">"/org\\.eurekaJ\\.manager\\..*/"</span>,
method=<span class="code-quote">"/.*/"</span>,
        location=@Location(value=Kind.ENTRY)
    )
    <span class="code-keyword">public</span> <span class="code-keyword">static</span> void componentPaintBefore(@ProbeClassName <span class="code-object">String</span> pcn, @ProbeMethodName <span class="code-object">String</span> pmn) {
        <span class="code-object">Long</span> timePeriod = ((timeNanos() / 15000000000l)*15000);
        
        Appendable a = Strings.newStringBuilder(<span class="code-keyword">true</span>);
        Strings.append(a, property(<span class="code-quote">"btrace.agent"</span>));
        Strings.append(a, <span class="code-quote">";"</span>);
        Strings.append(a, pcn);
        Strings.append(a, <span class="code-quote">";"</span>);
        Strings.append(a, pmn);
        Strings.append(a, <span class="code-quote">";"</span>);
        Strings.append(a, str(timePeriod));

Profiling.recordEntry(eurekaJProfiler, str(a));
    }

    @OnMethod(
clazz=<span class="code-quote">"/org\\.eurekaJ\\.manager\\..*/"</span>,
method=<span class="code-quote">"/.*/"</span>,
location=@Location(Kind.RETURN)
    )
    <span class="code-keyword">public</span> <span class="code-keyword">static</span> void componentPaintAfter(@Duration <span class="code-object">long</span> time, @ProbeClassName <span class="code-object">String</span> pcn, @ProbeMethodName <span class="code-object">String</span> pmn) {
        <span class="code-object">Long</span> timePeriod = ((timeNanos() / 15000000000l)*15000);
        
        Appendable a = Strings.newStringBuilder(<span class="code-keyword">true</span>);
        Strings.append(a, property(<span class="code-quote">"btrace.agent"</span>));
        Strings.append(a, <span class="code-quote">";"</span>);
        Strings.append(a, pcn);
        Strings.append(a, <span class="code-quote">";"</span>);
        Strings.append(a, pmn);
        Strings.append(a, <span class="code-quote">";"</span>);
        Strings.append(a, str(timePeriod));
        
Profiling.recordExit(eurekaJProfiler, str(a), time);
    }

    @OnTimer(7500)
    <span class="code-keyword">public</span> <span class="code-keyword">static</span> void printAverage() {         
        <span class="code-object">String</span> profilingFormat = strcat(<span class="code-quote">"[ProfilingV1;"</span>, property(<span class="code-quote">"btrace.agent"</span>));
        Profiling.printSnapshot(<span class="code-quote">"", eurekaJProfiler, "</span>[ProfilingV1;%1$s;%2$s;%3$s;%4$s;%5$s;%6$s;%7$s;%8$s;%9$s;%10$s;Custom]");
        Profiling.reset(eurekaJProfiler);
    }

}

num     #instances #bytes  class name
----------------------------------------------
   1:338311       66865200  [C
   2:495403       50713368  [B
   3:294009       28224864  com.sun.btrace.Profiler$Record
   4:338325       13533000  java.lang.String
   5: 75789       10906032  
   6:2392279569080  com.sleepycat.je.tree.LN
   7: 757899106696  
   8:  76268499360  
   9:  76225902272  
  10:1161915880808  
  11:  65405089824  

[reporter="jbachorik", created="Thu, 17 Dec 2009 12:44:58 +0100", resolved="Thu, 17 Dec 2009 14:25:45 +0100"]

When using a script like this

@BTrace
public class NoArgsEntryReturn {
    @OnMethod(clazz="/.*\\.OnMethodTest/", method="args")
    public static void argsEmptyEntry(@Self Object x) {
println("entry");
    }
@OnMethod(clazz=<span class="code-quote">"/.*\\.OnMethodTest/"</span>, method=<span class="code-quote">"args"</span>, location=@Location(value=Kind.RETURN))
<span class="code-keyword">public</span> <span class="code-keyword">static</span> void argsEmptyReturn(@Self <span class="code-object">Object</span> x) {

println("return");

}
}

[reporter="j.bachorik", created="Sun, 15 Jan 2012 20:28:17 +0100", resolved="Sun, 1 Apr 2012 21:14:02 +0200"]

Update the BTrace bundled ASM to version 4.0 - it should provide better support for JDK7.

[reporter="j.bachorik", created="Tue, 15 Mar 2011 13:37:05 +0100", resolved="Tue, 26 Jun 2012 13:43:48 +0200"]

This issue is described in this web forum topic.

In short - BTrace fails to resolve class hierarchy for the newly loaded classes as its superclasses and interfaces may not have been loaded yet at the time the BTrace agent needs to do the class transformation. Due to this lack of knowledge the subclass matching (clazz="+java.util.List" eg.) will not work correctly if the required supertype is further than one level from the class being processed (aka the immediate supertype and interface will work while their supertypes and interfaces will not).

[reporter="joachimhskeie", created="Sat, 19 Mar 2011 22:43:49 +0100"]

I had the idea that BTrace should be able to be extended via pluings to enable third party developers to write efficient add-ons to the BTrace system. I have made a first go at using the ServiceLocator thats bundled with Java 6, doing the following:

btrace-api.jar gets a new interface called com.sun.btrace.spi.BtraceProcessProvider
btrace-core gets a new Java class called com.sun.btrace.plugin.PluginService

BtraceUtils gets a new method Plugins.executePluginWithName(String pluginName) which will attempt to locate a plugin of the given name, and then call the "process()" method from within that plugin.

To enable dynamic loading of plugins, I have also added an agent-parameter "plugindir" that allows the user to specify where they have placed the directory containing their plugin .jar files.

I am attaching a schematic drawing of the proposed architecture, as well as a diff file for the mavenized core of BTrace. I would very much like to get some feedback on the validity to adding something like this to BTrace as I think it might serve as the basis for some very useful third party plugins.

[reporter="jbachorik", created="Wed, 27 Jan 2010 10:36:07 +0100", resolved="Wed, 27 Jan 2010 10:53:56 +0100"]

Code to reproduce the problem:

package com.sun.btrace.samples;
import com.sun.btrace.annotations.;

import static com.sun.btrace.BTraceUtils.;
/**

This script traces method entry into every method of
every class in javax.swing package! Think before using
this script -- this will slow down your app significantly!!

/

@BTrace(name="AllMethods") public class AllMethods {

@Property private static int cntr = 10;

@OnMethod(

clazz="/javax\.swing\../",

method="/.*/"

)

public static void m(@ProbeClassName String probeClass, @ProbeMethodName String probeMethod) {

print(strcat("entered ", probeClass));

println(strcat(".", probeMethod));

}

}

[reporter="m_hess", created="Fri, 2 Oct 2009 17:04:58 +0200", resolved="Mon, 19 Oct 2009 15:15:11 +0200"]

Regardless of the BTrace Context, the TLS implementation is flawed, since it does not provide a new instance for any given Thread. It simply stores the previously created SINGLE instance and hands it out to ALL Threads. So in the end, all TLS fields indeed are not Thread local at all. I have not spent much time about if and how this might work for Primitives, but for Objects this definitely is broken. One could probably argue, that this is only a problem in unsafe mode, but then again I do not see the Point in calling anything a ThreadLocal that is not one. In fact I think this is really dangerous because it is very misleading.

The implementation of BTraceRuntime.newThreadLocal(Object)
(http://kenai.com/projects/btrace/sources/hg/content/src/share/classes/com/sun/btrace/BTraceRuntime.java?rev=207)

{{
0441. public static ThreadLocal newThreadLocal(
0442.final Object initValue) {
0443.return new ThreadLocal() {
0444. @OverRide
0445. protected Object initialValue()

{
0446.return initValue;
0447. }

0448.};
0449. }
}}

In Practice it looks like this. Given is the following field in a Probe:

{{
@tls private static Deque timeDeque = new ArrayDeque();
}}

This gets compiled into the following code snippet:

{{
ArrayDeque arraydeque = new ArrayDeque();
$timeDeque = BTraceRuntime.newThreadLocal(arraydeque);
}}

As you can see, the arraydeque is given to the newThreadLocal() method, which stores a reference to the instance and hands it out later.

I have classified this as a blocker, since it makes trace pretty much unusable in any Multithreaded environment.

[reporter="jbachorik", created="Fri, 30 Jul 2010 14:32:39 +0200", resolved="Fri, 30 Jul 2010 14:40:38 +0200"]

Usage of IdentityHashMap in the ThreadEnteredMap has nasty consequences if someone wants to trace get() method of all java.util.Map subclasses - basically it crashes the traced VM.

[reporter="jbachorik", created="Mon, 17 May 2010 15:53:13 +0200", resolved="Tue, 18 May 2010 10:25:17 +0200"]

Observing the instrumentation progress (#BTRACE-33) causes out of order writes to the communication channels causing race conditions occasionally. This can lead to hangup of the traced application.

[reporter="jbachorik", created="Tue, 19 Oct 2010 14:21:54 +0200", resolved="Tue, 19 Oct 2010 15:49:27 +0200"]

When using the VisualVM BTrace plugin on Windows or Mac with the default installation of JDK (containing space in path) it is impossible to start tracing as the btrace compiler wrapper enters endless loop.

[reporter="joe_pallas", created="Tue, 14 Jun 2011 19:20:32 +0200", resolved="Sat, 18 Jun 2011 13:44:29 +0200"]

@duration arguments are documented to work with both EXIT and ERROR method locations. In the error case, however, the instrumented code doesn't compute or pass a duration argument, which makes the verifier complain about the missing argument.

In this example, two probes are defined:

@OnMethod(clazz="org.apache.hadoop.hbase.client.HTable", method="/.*/", location=@location(Kind.ERROR))
public static void error(@ProbeMethodName String probeMethod, @duration long duration)

{...}



@OnMethod(clazz="org.apache.hadoop.hbase.client.HTable", method="/.*/", location=@location(Kind.RETURN))

public static void exit(@ProbeMethodName String probeMethod, @duration long duration) {...}

The complaint is:

Exception in thread "main" java.lang.VerifyError: (class: org/apache/hadoop/hbase/client/HTable, method: getWriteBuffer signature: ()Ljava/util/ArrayList Expecting to find long on stack

The original code (as dumped by javap) for org.apache.hadoop.hbase.client.HTable.getWriteBufferSize() is:

public long getWriteBufferSize();
Code:
0: aload_0
1: getfield #23; //Field writeBufferSize:J
4: lreturn

The instrumented code is:

public long getWriteBufferSize();
Code:
0: invokestatic #93; //Method $btrace$time$stamp)J
3: lstore_1
4: aload_0
5: getfield#163; //Field writeBufferSize:J
8: invokestatic #93; //Method $btrace$time$stamp)J
11: lstore_3
12: ldc_w #689; //String getWriteBufferSize
15: lload_3
16: lload_1
17: lsub
18: invokestatic #98; //Method $btrace$HTableOps$exit:(Ljava/lang/String;J)V
21: lreturn
22: ldc_w #689; //String getWriteBufferSize
25: invokestatic #106; //Method $btrace$HTableOps$error:(Ljava/lang/String;J)V
28: athrow
Exception table:
from to target type
0 22 22 Class java/lang/Throwable

We can see that the exception code calls HTableOps.error with only one parameter instead of the two it expects, and there is no calculation of duration at all.

[reporter="j.bachorik", created="Mon, 8 Jul 2013 12:46:57 +0200", resolved="Fri, 13 Sep 2013 08:28:01 +0200"]

Currently, BTrace will not work when the client is run on a newer JDK (eg. JDK7) while the traced application runs an older JDK (eg. JDK6).

The reason for this is that BTrace uses the client's compiler to compile the trace file and this results in a class file of a version that the traced JVM can not understand. The BTrace compiler should compile to the lowest supported class file version to make sure the cross-version cooperation.

[reporter="mikhail.dmitriev", created="Fri, 22 Apr 2011 02:15:09 +0200", resolved="Sat, 18 Jun 2011 13:43:52 +0200"]

Below is a script and output that it produced. Hopefully it's sufficient to figure out the root cause

@btrace
public class TracingScript {

@OnMethod(clazz="/java\\.io
../", method="/read./")
public static void anyRead(@ProbeClassName String pClazz, @ProbeMethodName String pMethod, AnyType[] args)

{
print("Entered method ");
print(pClazz);
print(".");
print(pMethod);
println(" with arguments:");
printArray(args);
}

}

-------------------------------------

Entered method java.io.ObjectInputStream$BlockDataInputStream.read with arguments:
[]
Entered method java.io.ObjectInputStream$PeekInputStream.read with arguments:
[]
Entered method java.io.ObjectInputStream.readSerialData with arguments:
java.lang.NullPointerException
at javax.management.ObjectName.getSerializedNameString(ObjectName.java:1688)
at javax.management.ObjectName.toString(ObjectName.java:1779)
at com.sun.btrace.BTraceUtils$Strings.str(BTraceUtils.java:3795)
at com.sun.btrace.BTraceUtils.printArray(BTraceUtils.java:939)
at java.io.ObjectInputStream.$btrace$TracingScript$6$anyRead(ObjectInputStream.java)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
at sun.rmi.server.UnicastRef.unmarshalValue(UnicastRef.java:306)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:290)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
!!! Error occured

• • • Done

[reporter="joachimhskeie", created="Sun, 12 Sep 2010 13:25:26 +0200"]

I would like to be able to retreive the object count for instrumented classes. I am not sure if it is possible to automatically store this type of data in the Agent (or it it is a desirable feature of the BTrace Agent).

The reason for wanting this feature is because I need some sort of "mini" jmap -histo:live feature for the instrumented application. If maintaining a list of the instrumented classes and its current object count is both easy to implement and easy on the resources required this could be a nice addition to BTrace.

A BTrace script could retreive the data using the standard StringFormat approach as both Aggregation and Profiler has today, something like

Profiler.printObjectCount(String format)

I will be happy to assist in developing this feature, but I will need some pointers as to where in the code this might be added.

[reporter="j.bachorik", created="Thu, 10 Jul 2014 21:10:38 +0200", resolved="Mon, 21 Jul 2014 17:48:47 +0200"]

When measuring the duration of a high number extremely short methods the overhead associated with the invocation of the injected code and gathering timestamps adds overhead which distorts the real method execution time and slows down the measured application considerably.

By introducing the mechanism of sampling it would be possible to measure eg. each 10th invocation of a certain method to get statistically significant data without the slow-down and measurement distortion.

The sampling mechanism will use a user provided probability distribution for gathering relevant and meaningful data.

[reporter="mwongho", created="Fri, 14 May 2010 09:07:32 +0200", resolved="Wed, 14 Jul 2010 20:17:35 +0200"]

Trying to attach brace to Glassfish v3, but get a 'Connection refused'.

DEBUG: btrace debug mode is set
DEBUG: trackRetransforms flag is set
DEBUG: btrace unsafe mode is set
DEBUG: dumpClasses flag is set
DEBUG: dumpDir is .
DEBUG: assuming default port 2020
DEBUG: assuming default classpath '.'
DEBUG: compiling WebServiceTracker.java
DEBUG: compiled WebServiceTracker.java
DEBUG: attaching to 3205
DEBUG: checking port availability: 2020
DEBUG: attached to 3205
DEBUG: loading btrace-agent.jar
DEBUG: agent args: port=2020,debug=true,dumpClasses=true,dumpDir=.,systemClassPath=/usr/lib/jvm/java-6-sun/lib/tools.jar,probeDescPath=.
DEBUG: loaded btrace-agent.jar
DEBUG: registering shutdown hook
DEBUG: registering signal handler for SIGINT
DEBUG: submitting the BTrace program
DEBUG: opening socket to 2020
Connection refused

[reporter="pilfrich", created="Mon, 8 Aug 2011 13:58:40 +0200", resolved="Mon, 8 Aug 2011 15:10:38 +0200"]

Problem description
When using ThreadLocals (TLS) and having a lot of threads in the systems the BTraceRuntime class holds an Object[][][] ThreadEnteredMap which stores each thread data (in my case primarily ThreadLocals). After the thread is finished normally the garbage collector would remove the finished thread from the heap. The BTraceRuntime class holds each thread instance which causes memory leaks.

Steps-to-repeat
I've created an experiment with a program constantly starting new threads which execute a method. The method call is covered by a probe writing the current timestamp (timeNanos()) into a ThreadLocal (@tls). The thread is finished after the method call and all data should be removed by the GC after a while.

After 400k Threads the size of BTraceRuntime (analyzed with Eclipse MAT) is 109MB. After 700k Threads the size is 213MB. This goes on and on until the GC finally exceeds its time limit and you get an OutOfMemory.

[reporter="jbachorik", created="Fri, 8 Jan 2010 09:27:27 +0100", resolved="Wed, 27 Jan 2010 10:07:41 +0100"]

See http://kenai.com/projects/btrace/forums/forum/topics/2262-BTrace-1-1-Released#p6314

[reporter="lehuy20", created="Sun, 30 Oct 2011 18:15:45 +0100", resolved="Wed, 9 May 2012 14:10:10 +0200"]

[root@localhost btrace_samples]# java -version
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.10) (rhel-1.23.1.9.10.el5_7-i386)
OpenJDK Client VM (build 19.0-b09, mixed mode)
______

debug info

DEBUG: btrace debug mode is set
DEBUG: dumpClasses flag is set
DEBUG: dumpDir is .
DEBUG: assuming default port 2020
DEBUG: assuming default classpath '.'
DEBUG: reading SubtypeTracer.class
DEBUG: read SubtypeTracer.class
DEBUG: attaching to 25146
DEBUG: checking port availability: 2020
DEBUG: attached to 25146
DEBUG: loading /root/btrace/build/btrace-agent.jar
DEBUG: agent args: port=2020,debug=true,dumpClasses=true,dumpDir=.,systemClassPath=/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/lib/tools.jar,probeDescPath=.
btrace DEBUG: debugMode is true
btrace DEBUG: unsafeMode is false
btrace DEBUG: dumpClasses is true
btrace DEBUG: dumpDir is .
btrace DEBUG: stdout is false
btrace DEBUG: probe descriptor path is .
btrace DEBUG: parsed command line arguments
btrace DEBUG: System ClassPath: /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/lib/tools.jar
btrace DEBUG: starting agent thread
btrace DEBUG: starting server at 2020
btrace DEBUG: waiting for clients
DEBUG: loaded /root/btrace/build/btrace-agent.jar
DEBUG: registering shutdown hook
DEBUG: registering signal handler for SIGINT
DEBUG: submitting the BTrace program
DEBUG: opening socket to 2020
btrace DEBUG: client accepted Socket[addr=/127.0.0.1,port=34811,localport=2020]
DEBUG: sending instrument command
DEBUG: entering into command loop
btrace DEBUG: got instrument command
btrace DEBUG: verifying BTrace class
btrace DEBUG: verified 'SubtypeTracer' successfully
btrace DEBUG: created class filter
btrace DEBUG: preprocessing BTrace class SubtypeTracer
btrace DEBUG: preprocessed BTrace class SubtypeTracer
btrace DEBUG: creating BTraceRuntime instance for SubtypeTracer
btrace DEBUG: created BTraceRuntime instance for SubtypeTracer
btrace DEBUG: removing @OnMethod, @OnProbe methods
btrace DEBUG: removed @OnMethod, @OnProbe methods
btrace DEBUG: sending Okay command
btrace DEBUG: client SubtypeTracer: got com.sun.btrace.comm.OkayCommand@1f5d386
btrace DEBUG: about to defineClass SubtypeTracer
btrace DEBUG: defineClass succeeded for SubtypeTracer
btrace DEBUG: starting client command handler thread
btrace DEBUG: waiting for clients
btrace DEBUG: new Client created com.sun.btrace.agent.RemoteClient@14a8cd1
btrace DEBUG: filtering loaded classes
btrace DEBUG: injecting for java/util/Collections$EmptyIterator
java.lang.NullPointerException
at java.lang.Class.initAnnotationsIfNecessary(Class.java:3101)
at java.lang.Class.getAnnotation(Class.java:3050)
at com.sun.btrace.runtime.ClassFilter.isCandidate(ClassFilter.java:83)
at com.sun.btrace.agent.Client.transform(Client.java:146)
at sun.instrument.TransformerManager.transform(TransformerManager.java:188)
at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:385)
at sun.instrument.InstrumentationImpl.retransformClasses0(Native Method)
at sun.instrument.InstrumentationImpl.retransformClasses(InstrumentationImpl.java:144)
at com.sun.btrace.BTraceRuntime.retransform(BTraceRuntime.java:1000)
at java.util.Collections$EmptyIterator.(Collections.java)
at java.util.Collections.emptyIterator(Collections.java:2950)
at java.util.Collections$EmptySet.iterator(Collections.java:3084)
at java.lang.Class.initAnnotationsIfNecessary(Class.java:3101)
at java.lang.Class.initAnnotationsIfNecessary(Class.java:3100)
at java.lang.Class.initAnnotationsIfNecessary(Class.java:3100)
at java.lang.Class.initAnnotationsIfNecessary(Class.java:3100)
at java.lang.Class.getAnnotation(Class.java:3050)
at com.sun.btrace.runtime.ClassFilter.isCandidate(ClassFilter.java:83)
at com.sun.btrace.agent.Client.isCandidate(Client.java:315)
at com.sun.btrace.agent.Main$4.run(Main.java:416)
DEBUG: received com.sun.btrace.comm.OkayCommand@122cdb6
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
btrace DEBUG: skipping transform for BTrace class sun/reflect/generics/parser/SignatureParser
btrace DEBUG: skipping transform for BTrace class sun/reflect/generics/tree/TypeArgument
btrace DEBUG: skipping transform for BTrace class sun/reflect/generics/tree/TypeTree
btrace DEBUG: skipping transform for BTrace class sun/reflect/generics/tree/Tree
btrace DEBUG: skipping transform for BTrace class sun/reflect/generics/tree/SimpleClassTypeSignature
btrace DEBUG: skipping transform for BTrace class sun/reflect/generics/tree/FieldTypeSignature
btrace DEBUG: skipping transform for BTrace class sun/reflect/generics/tree/BaseType
btrace DEBUG: skipping transform for BTrace class sun/reflect/generics/tree/TypeSignature
btrace DEBUG: skipping transform for BTrace class sun/reflect/generics/tree/ReturnType
btrace DEBUG: skipping transform for BTrace class sun/reflect/generics/tree/ClassTypeSignature
btrace DEBUG: skipping transform for BTrace class sun/reflect/generics/scope/ClassScope
btrace DEBUG: skipping transform for BTrace class sun/reflect/generics/scope/Scope
btrace DEBUG: skipping transform for BTrace class sun/reflect/generics/scope/AbstractScope
btrace DEBUG: skipping transform for BTrace class sun/reflect/generics/factory/CoreReflectionFactory
btrace DEBUG: skipping transform for BTrace class sun/reflect/generics/factory/GenericsFactory
btrace DEBUG: skipping transform for BTrace class sun/reflect/generics/visitor/Reifier
btrace DEBUG: skipping transform for BTrace class sun/reflect/generics/visitor/TypeTreeVisitor
btrace DEBUG: injecting for java/lang/reflect/GenericArrayType
btrace DEBUG: skipping transform for BTrace class sun/reflect/annotation/AnnotationType
btrace DEBUG: injecting for java/lang/annotation/RetentionPolicy
btrace DEBUG: client SubtypeTracer: skipping transform for java/lang/annotation/RetentionPolicy
btrace DEBUG: skipping transform for BTrace class sun/reflect/annotation/AnnotationType$1
btrace DEBUG: skipping transform for BTrace class sun/reflect/annotation/ExceptionProxy
btrace DEBUG: injecting for java/lang/annotation/Retention
btrace DEBUG: injecting for java/lang/annotation/Inherited
btrace DEBUG: injecting for java/lang/Class$4
btrace DEBUG: client SubtypeTracer: skipping transform for java/lang/Class$4
btrace DEBUG: skipping transform for BTrace class sun/reflect/annotation/AnnotationTypeMismatchExceptionProxy
btrace DEBUG: skipping transform for BTrace class sun/reflect/annotation/AnnotationInvocationHandler
btrace DEBUG: injecting for java/lang/reflect/InvocationHandler
btrace DEBUG: injecting for java/lang/reflect/Proxy
btrace DEBUG: client SubtypeTracer: skipping transform for java/lang/reflect/Proxy
btrace DEBUG: injecting for java/util/WeakHashMap
btrace DEBUG: client SubtypeTracer: skipping transform for java/util/WeakHashMap
btrace DEBUG: injecting for java/util/WeakHashMap$Entry
btrace DEBUG: client SubtypeTracer: skipping transform for java/util/WeakHashMap$Entry
btrace DEBUG: injecting for java/util/AbstractList$Itr
btrace DEBUG: client SubtypeTracer: skipping transform for java/util/AbstractList$Itr
btrace DEBUG: injecting for sun/misc/ProxyGenerator
btrace DEBUG: injecting for sun/misc/ProxyGenerator$ConstantPool
btrace DEBUG: injecting for sun/misc/ProxyGenerator$ProxyMethod
btrace DEBUG: injecting for sun/misc/ProxyGenerator$MethodInfo
btrace DEBUG: injecting for sun/misc/ProxyGenerator$ConstantPool$ValueEntry
btrace DEBUG: injecting for sun/misc/ProxyGenerator$ConstantPool$Entry
btrace DEBUG: client SubtypeTracer: skipping transform for sun/misc/ProxyGenerator$ConstantPool$ValueEntry
btrace DEBUG: injecting for sun/misc/ProxyGenerator$ConstantPool$IndirectEntry
btrace DEBUG: client SubtypeTracer: skipping transform for sun/misc/ProxyGenerator$ConstantPool$IndirectEntry
btrace DEBUG: injecting for sun/misc/ProxyGenerator$FieldInfo
btrace DEBUG: injecting for sun/misc/ProxyGenerator$PrimitiveTypeInfo
btrace DEBUG: injecting for sun/misc/ProxyGenerator$ExceptionTableEntry
btrace DEBUG: injecting for $Proxy0
btrace DEBUG: client SubtypeTracer: skipping transform for $Proxy0
btrace DEBUG: injecting for java/lang/annotation/Target
btrace DEBUG: injecting for java/lang/annotation/ElementType
btrace DEBUG: injecting for java/lang/annotation/Documented
btrace DEBUG: injecting for $Proxy1
btrace DEBUG: client SubtypeTracer: skipping transform for $Proxy1
btrace DEBUG: injecting for java/util/AbstractList$ListItr
btrace DEBUG: client SubtypeTracer: skipping transform for java/util/AbstractList$ListItr
btrace DEBUG: client SubtypeTracer: skipping transform for java/lang/annotation/ElementType
btrace DEBUG: injecting for $Proxy2
btrace DEBUG: client SubtypeTracer: skipping transform for $Proxy2
btrace DEBUG: injecting for $Proxy3
btrace DEBUG: client SubtypeTracer: skipping transform for $Proxy3
btrace DEBUG: candidate class java.lang.ApplicationShutdownHooks added
btrace DEBUG: candidate class java.util.concurrent.FutureTask added
btrace DEBUG: candidate class java.lang.ref.Reference$ReferenceHandler added
btrace DEBUG: candidate class java.util.concurrent.ThreadPoolExecutor$Worker added
btrace DEBUG: candidate class java.io.File$1 added
btrace DEBUG: candidate class java.lang.Thread added
btrace DEBUG: candidate class java.lang.ref.Finalizer$FinalizerThread added
btrace DEBUG: candidate class java.io.Console$1$1 added
btrace DEBUG: added as ClassFileTransformer
btrace DEBUG: client SubtypeTracer: got com.sun.btrace.comm.RetransformationStartNotification@121ab80
DEBUG: received com.sun.btrace.comm.RetransformationStartNotification@12f0999
btrace DEBUG: calling retransformClasses (8 classes to be retransformed)
btrace DEBUG: client SubtypeTracer: instrumenting java/lang/ApplicationShutdownHooks
btrace DEBUG: client SubtypeTracer: instrumenting java/util/concurrent/FutureTask
btrace DEBUG: client SubtypeTracer: instrumenting java/lang/ref/Reference$ReferenceHandler
btrace DEBUG: client SubtypeTracer: instrumenting java/util/concurrent/ThreadPoolExecutor$Worker
btrace DEBUG: client SubtypeTracer: instrumenting java/io/File$1
btrace DEBUG: client SubtypeTracer: instrumenting java/lang/Thread
btrace DEBUG: client SubtypeTracer: instrumenting java/lang/ref/Finalizer$FinalizerThread
btrace DEBUG: client SubtypeTracer: instrumenting java/io/Console$1$1
btrace DEBUG: client SubtypeTracer: got com.sun.btrace.comm.OkayCommand@b0bad7
DEBUG: received com.sun.btrace.comm.OkayCommand@11f2ee1
btrace DEBUG: skipping transform for BTrace class com/sun/btrace/BTraceUtils$Strings
btrace DEBUG: skipping transform for BTrace class com/sun/btrace/comm/MessageCommand
btrace DEBUG: skipping transform for BTrace class com/sun/btrace/comm/DataCommand
btrace DEBUG: client SubtypeTracer: skipping transform for java/text/SimpleDateFormat
btrace DEBUG: client SubtypeTracer: skipping transform for java/text/DateFormat
btrace DEBUG: client SubtypeTracer: skipping transform for java/text/Format
btrace DEBUG: client SubtypeTracer: skipping transform for java/text/DateFormat$Field
btrace DEBUG: client SubtypeTracer: skipping transform for java/text/Format$Field
btrace DEBUG: client SubtypeTracer: skipping transform for java/text/AttributedCharacterIterator$Attribute
btrace DEBUG: client SubtypeTracer: skipping transform for java/util/Calendar
btrace DEBUG: client SubtypeTracer: skipping transform for java/util/GregorianCalendar
btrace DEBUG: client SubtypeTracer: skipping transform for sun/util/resources/CalendarData
btrace DEBUG: client SubtypeTracer: skipping transform for sun/util/resources/LocaleNamesBundle
btrace DEBUG: client SubtypeTracer: skipping transform for sun/util/resources/CalendarData_en
btrace DEBUG: client SubtypeTracer: skipping transform for java/text/DateFormatSymbols
btrace DEBUG: client SubtypeTracer: skipping transform for java/text/spi/DateFormatSymbolsProvider
btrace DEBUG: client SubtypeTracer: skipping transform for sun/text/resources/FormatData
btrace DEBUG: client SubtypeTracer: skipping transform for java/util/ListResourceBundle
btrace DEBUG: client SubtypeTracer: skipping transform for sun/text/resources/FormatData_en
btrace DEBUG: client SubtypeTracer: skipping transform for sun/text/resources/FormatData_en_US
btrace DEBUG: client SubtypeTracer: skipping transform for java/text/NumberFormat
btrace DEBUG: client SubtypeTracer: skipping transform for java/text/spi/NumberFormatProvider
btrace DEBUG: client SubtypeTracer: skipping transform for java/text/DecimalFormatSymbols
btrace DEBUG: client SubtypeTracer: skipping transform for java/text/spi/DecimalFormatSymbolsProvider
btrace DEBUG: client SubtypeTracer: skipping transform for java/util/Currency
btrace DEBUG: client SubtypeTracer: skipping transform for java/util/Currency$1
btrace DEBUG: client SubtypeTracer: skipping transform for java/util/spi/CurrencyNameProvider
btrace DEBUG: client SubtypeTracer: skipping transform for sun/util/resources/CurrencyNames
btrace DEBUG: client SubtypeTracer: skipping transform for sun/util/resources/CurrencyNames_en_US
btrace DEBUG: client SubtypeTracer: skipping transform for java/text/DecimalFormat
btrace DEBUG: client SubtypeTracer: skipping transform for java/text/FieldPosition
btrace DEBUG: client SubtypeTracer: skipping transform for java/text/DigitList
btrace DEBUG: client SubtypeTracer: skipping transform for java/math/RoundingMode
btrace DEBUG: client SubtypeTracer: skipping transform for java/lang/Character$CharacterCache
btrace DEBUG: client SubtypeTracer: skipping transform for java/util/IdentityHashMap$KeySet
btrace DEBUG: client SubtypeTracer: skipping transform for java/util/IdentityHashMap$KeyIterator
btrace DEBUG: client SubtypeTracer: skipping transform for java/util/IdentityHashMap$IdentityHashMapIterator
btrace DEBUG: client SubtypeTracer: got com.sun.btrace.comm.MessageCommand@fbb7cb
DEBUG: received com.sun.btrace.comm.MessageCommand@e0b6f5
java.io.Console$1$1btrace DEBUG: client SubtypeTracer: got com.sun.btrace.comm.MessageCommand@1df8b99
DEBUG: received com.sun.btrace.comm.MessageCommand@10bc49d
.btrace DEBUG: client SubtypeTracer: got com.sun.btrace.comm.MessageCommand@1462851
DEBUG: received com.sun.btrace.comm.MessageCommand@1995d80
run
btrace DEBUG: client SubtypeTracer: got com.sun.btrace.comm.MessageCommand@1010058
DEBUG: received com.sun.btrace.comm.MessageCommand@1c9b9ca
java.lang.ApplicationShutdownHooksbtrace DEBUG: client SubtypeTracer: got com.sun.btrace.comm.MessageCommand@bdab91
DEBUG: received com.sun.btrace.comm.MessageCommand@c4aad3
.btrace DEBUG: client SubtypeTracer: got com.sun.btrace.comm.MessageCommand@4ac00c
DEBUG: received com.sun.btrace.comm.MessageCommand@1ab28fe
run
btrace DEBUG: client SubtypeTracer: got com.sun.btrace.comm.MessageCommand@1865b28
DEBUG: received com.sun.btrace.comm.MessageCommand@105738
java.lang.Threadbtrace DEBUG: client SubtypeTracer: got com.sun.btrace.comm.MessageCommand@1cac6db
DEBUG: received com.sun.btrace.comm.MessageCommand@ce5b1c
.btrace DEBUG: client SubtypeTracer: got com.sun.btrace.comm.MessageCommand@1c56c60
DEBUG: received com.sun.btrace.comm.MessageCommand@1bfc93a
run
btrace DEBUG: client SubtypeTracer: got com.sun.btrace.comm.ExitCommand@4e280c
DEBUG: received com.sun.btrace.comm.ExitCommand@341960
btrace DEBUG: onExit: removing transformer for SubtypeTracer
+++ wait 25146
btrace DEBUG: client SubtypeTracer: skipping transform for java/io/EOFException
btrace DEBUG: java.io.EOFException
java.io.EOFException
at java.io.ObjectInputStream$BlockDataInputStream.readByte(ObjectInputStream.java:2738)
at java.io.ObjectInputStream.readByte(ObjectInputStream.java:912)
at com.sun.btrace.comm.WireIO.read(WireIO.java:37)
at com.sun.btrace.agent.RemoteClient$1.run(RemoteClient.java:72)
at java.lang.Thread.run(Thread.java:636)
btrace DEBUG: onExit: closing all

[reporter="ihepda", created="Tue, 7 Feb 2012 09:29:01 +0100", resolved="Tue, 2 Jul 2013 16:26:24 +0200"]

The dump of the stack trace using Threads.jstack or Threads.jstackStr dump the stack without the first stack of the business class.
For example:
ClassA.methodA call ClassB.methodB
ClassB.methodB call ClassC.methodC
ClassC.methodC call ClassD.methodD

ClassD.methodD is probed and in the probe method print the stack trace with Thrads.jstack

The output show the stack trace from ClassB.methodB

[reporter="jbachorik", created="Mon, 30 Aug 2010 11:21:40 +0200", resolved="Mon, 30 Aug 2010 11:24:33 +0200"]

When instrumenting certain methods in certain classes (eg. containing a calls to methods before the call to super constructor in a constructor or containg JSR/RET pairs) the resulting class files can become invalid and the class verification fails.

[reporter="sreeni", created="Sat, 31 Oct 2009 01:00:40 +0100", resolved="Wed, 25 Nov 2009 10:38:23 +0100"]

I started working on a glassfish v3 bug (link given below) related to reporting of incorrect stats as the data is not getting updated properly.

https://glassfish.dev.java.net/issues/show_bug.cgi?id=10485

Instead of showing the count as 20 it shows 10. The entry point for glassfish is Main.handleFlashLightClient. Once I replaced the btrace-agent.jar and btrace-boot.jar with previous version then the stats show up correctly.

Perhaps the fix provided for performance issues has caused this regression. Pl. look at the fixes provided for
http://kenai.com/jira/browse/BTRACE-12
http://kenai.com/jira/browse/BTRACE-13

Since our hard code freeze is few days away, we need this fix asap.

Appreciate your help.

[reporter="pilfrich", created="Tue, 28 Jun 2011 11:31:04 +0200", resolved="Tue, 28 Jun 2011 16:56:41 +0200"]

Actual Behavior
Running the AllSync example will result in only the second probe in order being activated. If you instrument the same class/method with different locations it seems that the second probe will overwrite the first one.

This behavior occurs in 1.1 and 1.2. In previous versions (1.0) everything works as expected.

Expected Behavior
It should be possible to instrument several locations within the same class/method.

Steps-to-Repeat

• Write a sample program executing a synchronized block or method.
• Run the AllSync example and check if both outputs are printed.

[reporter="mjakl", created="Mon, 3 Oct 2011 00:32:57 +0200", resolved="Tue, 18 Oct 2011 12:24:30 +0200"]

The check for inner classes stumbles over the Profiling.java example.

The class of the example is "Profiling" and the class of the profiler is also called "Profiling" leading to:

com.sun.btrace.VerifierException: nested and inner classes are not allowed
at com.sun.btrace.runtime.Verifier.reportError(Verifier.java:390)
at com.sun.btrace.runtime.Verifier.reportError(Verifier.java:381)
at com.sun.btrace.runtime.Verifier.visitInnerClass(Verifier.java:155)
at com.sun.btrace.org.objectweb.asm.ClassReader.accept(Unknown Source)
at com.sun.btrace.org.objectweb.asm.ClassReader.accept(Unknown Source)
at com.sun.btrace.runtime.InstrumentUtils.accept(InstrumentUtils.java:66)
at com.sun.btrace.runtime.InstrumentUtils.accept(InstrumentUtils.java:62)
at com.sun.btrace.agent.Client.verify(Client.java:391)
at com.sun.btrace.agent.Client.loadClass(Client.java:218)
at com.sun.btrace.agent.RemoteClient.(RemoteClient.java:59)
at com.sun.btrace.agent.Main.startServer(Main.java:379)
at com.sun.btrace.agent.Main.access$000(Main.java:65)
at com.sun.btrace.agent.Main$3.run(Main.java:166)
at java.lang.Thread.run(Thread.java:662)

btracec does not complain, but running the example with "btrace PID Profiling.java" fails.

Renaming the Profiling.java example to ProfilingDemo.java fixes the symptom.
Probably "visitInnerClass" should not be called for fields?

[reporter="joachimhskeie", created="Tue, 3 Dec 2013 10:24:24 +0100", resolved="Fri, 27 Dec 2013 17:36:12 +0100"]

When Apple stopped making the JVM for Macs, and Oracle took over with java 7, there is no tools.jar file anymore, as JVM 7 uses the standard classes.jar file instead.

Added a fix in the btracec script (revision 460), that allows btracec to execute on Macs with Oracle JVMs.

Please review the changes

[reporter="jbachorik", created="Thu, 12 Aug 2010 16:55:19 +0200", resolved="Fri, 20 Aug 2010 12:42:26 +0200"]

As of now @onexit handler is called only when BTraceUtils.exit() method is called. It should be called upon exiting the traced application, too.

[reporter="jim.bim", created="Thu, 4 Jul 2013 01:19:46 +0200", resolved="Thu, 4 Jul 2013 01:23:26 +0200"]

The new btrace does no longer run on Java 6, complaining about classfile version 51.0 (meaning that the codebase was compiled with Java 7). I wonder if the files could be compiled with 1.6 classfile compatibility - that would allow using btrace on Java 6 again.

One trouble of this is the Verifier class that references Java7-only enum value (SourceVersion.RELEASE_7), so the compiler won't work on Java 6. But I think it could be solved as well:
1) There would be Verifier (6-compatible) and Verifier7 (extends Verifier and adds the annotation for 7). Compiler would then try to create Verifier7 by reflection and if it's unsuccessful, it would fall back to plain Verifer.
2) Perhaps the Verifier subclass with the proper annotation could be generated dynamically? As a bonus, we would get the issue solved for all future JVMs.

What is the plan for supporting Java 6 anyway?

[reporter="joachimhskeie", created="Mon, 26 Apr 2010 20:25:12 +0200", resolved="Tue, 18 May 2010 20:24:53 +0200"]

I would like to be able to maintain a list of the number of active calls to a method. For this to work I need to be able to increment a count when the method is entered, and to later be able to decrement the count when the method is exited.

I propose a small change in Count.java that will decrement the Count Aggregation if the value specified is negative. Attaching Diff file.

One possible BTrace script to make us of this is to monitor active threads by thread type (Currently being worked on as part of http://jira.codehaus.org/browse/EUREKAJ-20).

[reporter="klynch", created="Thu, 12 Aug 2010 08:28:24 +0200", resolved="Thu, 12 Aug 2010 14:14:37 +0200"]

The @ontimer annotation creates a non-daemon Timer object that continues to run even after the traced application exits. When experimenting with the provided ThreadCounter btrace script, the Timer thread continues to run. When the @ontimer annotation is commented out, the traced application halts.

{{java -javaagent:$

{BTRACE_HOME}

/build/btrace-agent.jar=stdout=true,noServer=true,script=ThreadCounter.class ThreadTest}}

By configuring the Timer object to use daemon threads, the traced application correctly exits.

[reporter="jerusalemer", created="Thu, 13 Oct 2011 18:18:22 +0200"]

The existing ability to go a specific line in method can become much more usable if there is an ability to find out the values of local variables at that specific line.

[reporter="j.bachorik", created="Fri, 25 Jul 2014 22:45:51 +0200", resolved="Mon, 28 Jul 2014 19:56:38 +0200"]

Changes in instrumentors caused subtle errors when injecting BTrace code resulting in VerifyError thrown when instrumenting certain classes.

[reporter="joachimhskeie", created="Sat, 17 Jul 2010 23:09:55 +0200", resolved="Mon, 23 Aug 2010 22:34:50 +0200"]

Often when reporting on Average Execution times for classes, I would like to be able to report on both the average execution time and the number of executions that average is calculated from via the same printAggregation method.

I am attaching a diff file that adds a "CountingAverage" aggregation type, extending from the Average aggregation type. I am also modifying the GridDataCommand to support the new CountingAverageData class.

I am not quite happy with the following, although I dont have any good suggestions for improvements without refactoring the methods signatures:

• the instanceof in the GridDataCommand makes for (potentially) bloated code if new aggregation data types are added
• I would like for the CountingAverageData to be able to use a custom StringFormat to format its output, but the API available via BTraceUtils does not allow information about this to be set.

Another approach to this issue would be to add a method printAggregation(String stringFormat, Aggregation ... aggregationArray) that would combine the results from multiple aggregations for output, assuming they use the same AggregationKey. This might be the better option in this (and other) case(s). I could have a look into a possible solution to this if you would rather see this type of solution.

[reporter="j.bachorik", created="Tue, 2 Jul 2013 12:57:38 +0200", resolved="Tue, 2 Jul 2013 16:25:41 +0200"]

The latest JDK7 update broke BTrace.

An attempt to attach to an application results in

Exception in thread "Thread-0" java.lang.ExceptionInInitializerError
    at com.sun.btrace.agent.Main.startServer(Main.java:379)
    at com.sun.btrace.agent.Main.access$000(Main.java:65)
    at com.sun.btrace.agent.Main$3.run(Main.java:166)
    at java.lang.Thread.run(Thread.java:724)
 Caused by: java.lang.SecurityException: unsafe init
    at com.sun.btrace.BTraceRuntime.init(BTraceRuntime.java:382)
    at com.sun.btrace.agent.Client.(Client.java:94)
    ... 4 more

This is caused by sun.reflect.Reflection.getCallerClass(int) requiring one additional frame to skip when trying to get the immediate caller.

[reporter="joachimhskeie", created="Tue, 26 Jan 2010 20:34:41 +0100", resolved="Fri, 23 Apr 2010 13:14:08 +0200"]

Reporting memory usage is one part of analyzing memory issues. Linked with situations like memory leaks is increased time spent in garbage collection. As the problem increases GC is all the application spends time on.

This can be implemented in more than one way, one being probing the GC MXBean every ten or fifteen seconds, to be able to calculate the total time in percent spent in GC during the last, say 15 or 20 minuttes. As far as I know the JVM will attempt to spend about one percent of its time performing GC.

I assume some code needs to go into BTraceRuntime, and some into a BTrace Script.

I might attach one possible solution if I can fins the time.