Remote Debugging on the Last Day of - Day 10: Building DDTJ

Yesterday the DDT PoC started working, today is the last day of my two-week “hack fest” on DDTJ… Here's where we stand.

The second week is finally over and while I built a working DDT proof of concept. I wasn’t able to complete a fully working MVP. The difference is that a proof of concept shows something working, an MVP needs to do something useful. DDT has yet to be realistically useful.

Making DDT useful is my main goal right now. To facilitate that, I’m trying to get it to work with a Spring Boot application. So far this isn’t going great, but I’m making iterative progress. Running the application like we do a “hello world” just doesn’t work. The backend is blocked and the launch method never returns. 

Spring Boot has a relatively elaborate bootstrap loading phase which causes issues with debuggers. The approach is to bind a remote debugger that wasn’t supported by DDTJ, so I added that support.

With remote debugging and some command-line magic for spring boot, I was able to connect to the spring boot VM and got the whole thing working.

Weird Bugs

Right now I’m in a bug squashing phase. Run the spring boot pet clinic app with remote debugging. Launch the backend. Connect them and find a bug. Fix, rinse, repeat. 

This is tedious, but mostly running smoothly. 

Unfortunately, I seem to run into issues that are very hard to debug. E.g. Unexpected JDWP Error: 32 which is thrown by the JDI implementation. This seems like an issue with stack frames, but I can’t figure out why it’s happening.

Another problem is that on a method entry event, the stack seems to be occasionally “corrupted”. Where the current method isn’t at the top of the stack. As far as I can tell, this isn’t something that should ever happen. But I might have missed a documentation nuance.

Attaching a Debugger

We can attach a debugger using the process id with a command like:

java -jar target/CLI-0.0.6-SNAPSHOT-shaded.jar -pid=62604

Or we can use a socket. Notice the socket always connects to localhost as remote debugging is a danger over JDWP:

java -jar target/CLI-0.0.6-SNAPSHOT-shaded.jar -attach=8000

Notice that the backend should have been running before and the pet clinic demo. I used the following command for the pet clinic:

java -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000 -jar spring-petclinic-2.5.0-SNAPSHOT.jar -Dagentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8000

Which might have been a bit much, but it took me forever to get the damn thing to connect through JDWP.

Upcoming PR and Where do we go Next?

This code is in a PR that still isn’t running the spring boot pet clinic. As such, I don’t want to commit it yet or create a PR. Unfortunately, the two-week vacation is over and I have other duties.

I’ll reduce my work pace on DDT for now as I have a lot of catching up to do at work. But I plan to bring it to MVP status within 2-4 weeks. I think the slower pace might help me digest some of these issues. So overall, it’s probably a good thing to take a bit of a break.

I made a lot of mistakes in the past two weeks, but I think I’m too close to it right now. I’ll try to write a post-mortem post next week to cover what I did well and what I can improve. This won’t be a summary, as I think my opinions on this will evolve further as I rethink some of my stances.

I suggest watching the DDTJ project to see when it gets updated with a new PR. You can also follow me on Twitter to keep up to date with the latest developments. 

I have some great ideas for the core technology of DDT that go well beyond testing alone. There’s a lot of untapped potentials here that we need to explore.