Byte Buddy version update

[kamko]

Continuing the investigation.

Caused by: java.lang.NegativeArraySizeException: -1
	at tech.httptoolkit.relocated.net.bytebuddy.utility.dispatcher.JavaDispatcher$DynamicClassLoader.invoker(SourceFile:34)
	at tech.httptoolkit.relocated.net.bytebuddy.utility.dispatcher.JavaDispatcher$Invoker$CreationAction.run(SourceFile:1)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at tech.httptoolkit.relocated.net.bytebuddy.utility.dispatcher.JavaDispatcher.<clinit>(SourceFile:12)

This exception starts from version 1.11.6. By looking at the generated source mapping I see that the attempt to create array with negative size is at this line:
https://github.com/raphw/byte-buddy/blob/c51396ba504c0a7397d912f8e621d060bc360483/byte-buddy-dep/src/main/java/net/bytebuddy/utility/dispatcher/JavaDispatcher.java#L1270

Which fails as in the byte code Invoker interface was replaced with concrete class (in this commit it's Unsafe which is a class and has hashCode which has zero arguments... so my guess it's that it fails on this.

-- fast forward to latest byte buddy

Return value of JavaDispatcher.invoker() is net.bytebuddy.utility.Invoker interface but in the byte code (after r8) it is substituted with DirectInvoker class which again has one method with 0 arguments.

The exception is thrown at this line:
https://github.com/raphw/byte-buddy/blob/master/byte-buddy-dep/src/main/java/net/bytebuddy/utility/dispatcher/JavaDispatcher.java#L1287

This can be fixed by leaving the Invoker interface untouched by adding

-keep class tech.httptoolkit.relocated.net.bytebuddy.utility.Invoker { *; }

to r8-rules.txt. This way the interface is not replaced and byte buddy is able to create DynamicClassloader.

Afterwards the agent is able to attach to processes like before and we reach the second (or actually it is the first issue).

Since version 1.11.3 we are greeted by multiple SSLHandshakeExceptions during tests:

Unexpected failure for new http-url-conn: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

I currently have no idea what caused this... yet...

---

Looking at the standalone test the exception is also there (but it manages to succeed?)
https://github.com/httptoolkit/jvm-http-proxy-agent/runs/4601280285?check_suite_focus=true

[pimterry]

Thanks for continuing the investigation @kamko, this is really interesting! I haven't found time to properly look into the details yet myself, but I should have some time next week to dig into this and see if I can work out what's up with those SSL handshake exceptions... Watch this space. Do let me know if you manage to make any more progress yourself.