open-telemetry/opentelemetry-java-instrumentation

Opentelemetry javaagent causes debugging of javax.servlet.Filter to break in eclipse

DeepakAgr1411 opened this issue · 7 comments

Opentelemetry javaagent causes debugging of javax.servlet.Filter to break in eclipse. Debugging works fine if I remove the Opentelemetry javaagent. Please see the screenshot for better understanding.

image

Below is a test project to reproduce the issue. Start both applications in debug mode with breakpoint in TestFilter class and hit localhost:8080
prj.zip

Using below VM arguments
-javaagent:C:\opentelemetry-javaagent-all.jar
-Dotel.exporter=jaeger
-Dotel.exporter.jaeger.endpoint=localhost:14250

opentelemetry-javaagent - version: 0.12.0

Eclipse Version: 2020-06 (4.16.0)
Build id: 20200615-1200

Javaagent injects a lot of new bytecode into instrumented classes to automatically generate telemetry. As there is no actual source code corresponding to that bytecode, Eclipse cannot display.

I don't think there is anything that we can do. Why do you want to debug your application together with agent?

@iNikem Consider the application being in containerized development environment, it would be a real pain to remove the javaagent everytime I need to debug the application.

Combination of tracing and metrics from OpenTelemetry along with remote debugging would make a great debugging experience, don't you think?

I am not sure this is our primary use-case :)

trask commented

hey @DeepakAgr1411, try hitting F6 (step-over) some number of times to get past the injected bytecode at the beginning of the method

I believe this should be reported to bytebuddy. The problem is that when inserting advice bytebuddy renumbers local variables. Ideally it should keep this and method arguments in the slots they were. For example local variable table from HttpServlet.service looks like this after instrumentation

      LocalVariableTable:
        Start  Length  Slot  Name   Signature
          137      10     8 request   Ljavax/servlet/http/HttpServletRequest;
          144       3     9 response   Ljavax/servlet/http/HttpServletResponse;
          149      16    10     e   Ljava/lang/ClassCastException;
          130      47     5  this   Ljavax/servlet/http/HttpServlet;
          130      47     6   req   Ljavax/servlet/ServletRequest;
          130      47     7   res   Ljavax/servlet/ServletResponse;
          165      12     8 request   Ljavax/servlet/http/HttpServletRequest;
          165      12     9 response   Ljavax/servlet/http/HttpServletResponse;

originally it was

      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            5       9     3 request   Ljavax/servlet/http/HttpServletRequest;
           11       3     4 response   Ljavax/servlet/http/HttpServletResponse;
           16      16     5     e   Ljava/lang/ClassCastException;
            0      40     0  this   Ljavax/servlet/http/HttpServlet;
            0      40     1   req   Ljavax/servlet/ServletRequest;
            0      40     2   res   Ljavax/servlet/ServletResponse;
           32       8     3 request   Ljavax/servlet/http/HttpServletRequest;
           32       8     4 response   Ljavax/servlet/http/HttpServletResponse;

It would also be good to realign validity region for this and method arguments to cover the whole method, otherwise variables may not appear when method breakpoints are used.

@trask @laurit @DeepakAgr1411 I understand that this issue can be closed? As it is a problem with ByteBuddy, not OpenTelemetry?

Closing as per previous comments