![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Moving-code-around debugger?
Jan. 25th, 2019 05:03 pmToday I worked on a problem where Thing happens but if I do a Prevention before what triggers Thing then all is fine. I did a successful Prevention in place X then it was suggested to me that it would be better if I did Prevention in place Y instead, a method of a Java class from a different JAR. I thought that this would be fine but it failed to prevent the Thing.
I spent a fair bit of time today verifying that Prevention at Y still happens before Thing, learning all about the background of what goes on with Thing, looking for other causes of Thing, other ways to prevent it, etc. Perhaps more promptly I should have attended to the simpler question: If Prevention at X works yet Prevention at Y does not then, regardless of that they both happen before Thing, what about at other places between X and Y?
I realized that an automated bisection tool would have been very helpful: even across JARs, move the Prevention to different parts of the code path from which X first reaches Y to find Z, the intermediate point before which the Prevention must happen. The nature of that Z could be most revealing. It being Java one can easily instrument the virtual machine to discover what that code path is.
Fortunately I had a thought about what might stop Prevention from working then found one in between X and Y that experimentation strongly suggests is indeed such a Z. That discovery was a nice way to end the week.
Update: For those who are interested: Thing was an SSL exception, Prevention adjusted the TLS configuration affecting SSLEngine, Z was the location of a non-TLS web interaction with an http://… URL.
I spent a fair bit of time today verifying that Prevention at Y still happens before Thing, learning all about the background of what goes on with Thing, looking for other causes of Thing, other ways to prevent it, etc. Perhaps more promptly I should have attended to the simpler question: If Prevention at X works yet Prevention at Y does not then, regardless of that they both happen before Thing, what about at other places between X and Y?
I realized that an automated bisection tool would have been very helpful: even across JARs, move the Prevention to different parts of the code path from which X first reaches Y to find Z, the intermediate point before which the Prevention must happen. The nature of that Z could be most revealing. It being Java one can easily instrument the virtual machine to discover what that code path is.
Fortunately I had a thought about what might stop Prevention from working then found one in between X and Y that experimentation strongly suggests is indeed such a Z. That discovery was a nice way to end the week.
Update: For those who are interested: Thing was an SSL exception, Prevention adjusted the TLS configuration affecting SSLEngine, Z was the location of a non-TLS web interaction with an http://… URL.
