Thank you, Oleg, There are three layers of code here, my app code, the http client code, and the JNA. All the manipulation of WindowsNegotiateScheme is done internally by http client code, through the WindowsNegotiateSchemeFactory. Perhaps there is something I need to do in my application, in terms of cleaning, but I just do not see when and how. Another possibility is that the WindowsNegotiateScheme is somehow mismanaged by AuthenticationStrategyImpl? Just a wild guess here...
I would like to hear from JNA team, what condition on the application side would cause the GPF in the native code to help us understand what is going wrong on a higher level. Unfortunately, I can not figure out how to post a question on https://github.com/java-native-access just unable to find anything like forums or support. Appreciate your help Alex From: Oleg Kalnichevski <ol...@apache.org> To: Alexander Bernstein <alexbernstein1...@yahoo.com> Cc: "httpclient-users@hc.apache.org" <httpclient-users@hc.apache.org> Sent: Thursday, August 27, 2015 4:18 AM Subject: Re: GPF in WindowsNegotiateScheme.dispose() On Wed, 2015-08-26 at 20:07 +0000, Alexander Bernstein wrote: > Hello, > I am new here, please pardon if this is not the right place for this kind of > question. > I am using httpclient-win-4.5 from httpClient 4.5 and > jna-4.1.0/jna-platform-4.1.0 JNA libraries to authenticate to Kerberos server > from Eclipse-based application. > I create my client from WinHttpClients.custom(). The authentication is > successful, but sooner or later, when JVM calls > WindowsNegotiateScheme.dispose() my Eclipse crashes with GPF. > I noticed that WindowsNegotiateSchemeFactory.create() is called twice, for > some reason. Not sure if this is a normal flow and/or is relevant to the > problem. > > 1XMCURTHDINFO Current thread > NULL ---------------------- > 3XMTHREADINFO "Finalizer thread" J9VMThread:0x0000000003FD1B00, > j9thread_t:0x00000000050C1F10, java/lang/Thread:0x000007FFDE5E2800, state:R, > prio=5 > 3XMJAVALTHREAD (java/lang/Thread getId:0x15, isDaemon:true) > 3XMTHREADINFO1 (native thread ID:0xCBC, native priority:0x5, > native policy:UNKNOWN, vmstate:R, vm thread flags:0x00000000) > 3XMTHREADINFO3 Java callstack: > 4XESTACKTRACE at com/sun/jna/Native.setPointer(Native Method) > 4XESTACKTRACE at > com/sun/jna/Pointer.setPointer(Pointer.java:1195) > 4XESTACKTRACE at com/sun/jna/Memory.setPointer(Memory.java:658) > 4XESTACKTRACE at com/sun/jna/Pointer.setValue(Pointer.java:937) > 4XESTACKTRACE at > com/sun/jna/Structure.writeField(Structure.java:800) > 4XESTACKTRACE at > com/sun/jna/Structure.write(Structure.java:718(Compiled Code)) > 4XESTACKTRACE at > com/sun/jna/Structure.autoWrite(Structure.java:1923(Compiled Code)) > 4XESTACKTRACE at > com/sun/jna/Function.convertArgument(Function.java:505(Compiled Code)) > 4XESTACKTRACE at > com/sun/jna/Function.invoke(Function.java:297(Compiled Code)) > 4XESTACKTRACE at > com/sun/jna/Library$Handler.invoke(Library.java:212) > 4XESTACKTRACE at > com/sun/proxy/$Proxy13.FreeCredentialsHandle(Bytecode PC:18) > 4XESTACKTRACE at > org/apache/http/impl/auth/win/WindowsNegotiateScheme.dispose(WindowsNegotiateScheme.java:99) > 4XESTACKTRACE at > org/apache/http/impl/auth/win/WindowsNegotiateScheme.finalize(WindowsNegotiateScheme.java:117) > 4XESTACKTRACE at > java/lang/J9VMInternals.runFinalize(J9VMInternals.java:436) > 3XMTHREADINFO3 No native callstack available on this platform > NULL > Appreciate any help and suggestions.Thank you > Alex Bernstein No matter what we might be doing wrong on our end this still looks like something that should not be happening. You probably should report the issue to JNA developers. https://github.com/java-native-access Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
