![]() So the example I showed before of connecting to a local host server, would work perfectly with this remote host as SSH will move all the packets back and forth. For both sides it will seem like local debugging. Just use this command to open a tunnel between the remote machine to your local machine. But there’s a very partial workaround of tunneling it over SSH. Locally on your own machine it isn’t a problem, but it has almost no security protections. JDWP is very insecure when used remotely. An open door isn’t a security vulnerability. That would be like putting your house keys and home address wrapped in a nice gift wrapping with an itemized list of your valuables sorted by value in front of your house. A good example would be debugging a container on your own machine. In some cases running the server locally in the IDE is impractical. I can set a breakpoint, step over, inspect variables etc. Once that is done this feels and acts like any debugger instance launched from within the IDE. We are now instantly connected to the running process. Next we need to press the debug button to run this command. But when we want to do remote debugging we need to toggle it here. We can switch to a different configuration from the same location. We now have a new Debug Remote run configuration. This lets us verify that we entered everything correctly. The IDE is showing us how to set up the command line for the remote process. Seems familiar? That’s the exact line we discussed before. Notice there are many options to tune here, but we don’t need any of them. I give the new run configuration a name, and we’re ready to go with debugging the app. Notice it’s pre-configured with the defaults such as port 5005. Next we need to locate a configuration for remote debugging. To start debugging we need to edit the run configuration in intellij. In this case I’m just running the PrimeMain class. Typically you would have something more substantial here. This is the rest of the command, the class we’re running. This is probably the better approach, although it won’t make the protocol fully secure. I can limit this to localhost only by changing the star character. In this case I allow anyone to connect on port 5005. This is the address and port we are listening on. If you set it to yes with the letter y the vm will pause on launch and wait for the JDWP connection. I’ve set this to no which means the VM will start running right away. We can optionally suspend the virtual machine on launch if you want to debug something right from the start. This isn’t useful usually but speaks to the power and flexibility of the API. This is actually pluggable, and you can build your own JDWP transport. This is faster and useful for processes that have access to a shared memory area. We can use dt_shmem which stands for shared memory as the wire protocol. In this case we transfer the details via a server socket. The IDE can then query the details about the current environment, stack, variables, etc. When the breakpoint is hit JDWP sends back an event to the IDE indicating that. When you add a breakpoint the IDE sends a JDWP command to add a breakpoint at the given location. You don’t need to know too much about JDWP but the concept is simple, you send commands and can query the system. Typically, it’s implemented over TCP sockets, but it’s the same protocol we used to debug devices directly. It’s a high level protocol, that means it can be implemented on top of various transports. This is the underlying networking protocol used to communicate between the debugger and the running process. Without this quote the command won’t work properly.Īgent lib is the system that loads the native library wiring directly into the virtual machine and JDWP is the Java Debug Wire Protocol. We need quotes in bash since there’s a star at the end of the line and bash wants to expand it. The first part is the launch of the Java command line. Let’s go over the command and break it down piece by piece to see that we understand it correctly. This is how these things work under the hood. When you inspect your maven or gradle files you might see many of the arguments listed here. Notice that this is a simplified version, in many cases the argument should be embedded in configuration files. To do that we need to run a command similar to this one. ![]() We first need to run the process that we’ll connect to remotely. We’ll start with a discussion around the connection. ![]() How to connect, how to make it slightly less vulnerable to security attacks, and then we’ll discuss the problems of remote debugging. We’ll delve more into that later but for now we’ll discuss the basic mechanics. Remote debugging doesn’t always deal with a remote machine, we often need it when debugging into Kubernetes or Docker. Welcome back to the ninth part of debugging at scale where we really know the quality of your code.
0 Comments
Leave a Reply. |