Not an LDAP expert, but I see that abandonRequest() still wants to write into outStream. If the SASL/GSS context is already disposed by now what stream should this be? Should it be reverted back to the raw stream?
Thanks, Weijun > On Jun 12, 2025, at 12:42, Osipov, Michael (IN IT IN) > <michael.osi...@innomotics.com> wrote: > >> Hi Michael, >> Please share a working copy of the code to duplicate the failure scenario of >> NPE related to Connection.java. BTW, I checked the stack trace posted on >> April 28 it did not clearly show Connection::cleanup got called. Was there >> something missed? > > Hi Weibing, > > apologies, it took me some time to respond. Here is the Java code in > question: https://gist.github.com/michael-o/8cff749d3ce5536bf70a16a64819cf10. > Please also find here some screenshots > (https://people.freebsd.org/~michaelo/ad-gssapi-tls-npe/) from my debugger > showing the cause. > > There is, indeed, something you missed: The Connection object is run > asynchronously is a separate thread. ::run() invokes the SASL input stream > which throws an IOE because the SASL receive buffer size is too large. The > exception is caught and swallowed. finally{} is called, it calls ::cleanup(). > Meanwhile the LDAP client receives the connection closure from the server, > the client tries to abandon the request and invokes the SASL client which is > already disposed by the connection. Therefore you don't see the > Connection::cleanup() method in the stack trace. If you pay a close look at > the output of ldapsearch(1) you will see that there are two errors: (1) the > buffer size mismatch and (2) the connection closure from the server. The > first issue causes the second to fail in JNDI/LDAP. > > Michael
