Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 305
  • Last Modified:

JNI/Win32 SOCKET help

I'm encountering a problem when I try to use a C DLL that has a Win32 SOCKET object.  When I open and close a connection within one JNI method call, it works fine.  But when I open a connection in one JNI call and close on a different JNI call, the JVM is crashes.  This is the error that I get:

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x102141EB

Does anybody know what the problem is, and what possible solutions/work-arounds there are?
1 Solution
>>Does anybody know what the problem is

Without code - no.
That's because the socket's handle you get from the first method (open) is invalid at the second method (close).

Each JNI method is runs on its own context (process segment). On the first method, when you open a socket you get the handle that is valid on the first context.
When you call the other method, it is executed on another context, and the socket handle (which is relative to the first context) will refer to the area outside the second context. So ... access violation happens.

I wonder why do you need to do socket operation with native C++ ? Java has net packages that will do that nice and portable.

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

RadfordAuthor Commented:
>> I wonder why do you need to do socket operation with
>> native C++ ? Java has net packages that will do that
>> nice and portable.

Why does anybody need to use JNI?  :)
Because there's already C code written to do what we need to do and we don't want to re-write the entire thing in Java.  Anyway thanks for the help.  I'll look into those links you mentioned and if they're any help, I'll give you the points.

- r
Kocil, please cite references for your 'theories' regarding memory management with JNI.  IIRC, What you are saying is false (or at least worded strangely to me.)  If you need to share variables across function calls, obviously you can't use locals.  However, if you have an object that you create when dllmain is called attaching to the dll, that object will remain valid until you delete it or the dll is unloaded.

RadfordAuthor Commented:
to clarify, the Win32 SOCKET object is actually contained in third-party code that we use.  it has an Open and Close function that returns a reference to a third party object that contains the SOCKET object.  perhaps the problem is not in the SOCKET object itself, but the third party code, or the way that the JVM is handling the dll, but i can't see how it's a problem with the third party code since as far as it is concerned, it is just being called regularly by C code.  it doesn't know that a JVM is calling it.
RadfordAuthor Commented:
alright my colleague and i solved the problem on our own.  =)

i'll just give the points to Kocil anyway for trying to help.  
> that object will remain valid until you delete it or the dll is unloaded.

I thought he has 2 methods on 2 different DLLs.
Thanks for the points :)

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now