What I am trying to do is to access methods in a dll from Java (using JNI).

I can call native methods, ie: isZipFile(.... ) extractZip(.... ).

I am sending 1 - n files to be checked, or extracted -- and it is crashing out.

I'm calling the native method for each file... ie:

isZipFile(String fileName);

Would this crash out if the method is processing/executing the last file, and it's called before the method has completed?

04-12-2007

itsme86

It should only crash if you don't implement proper error checking. If you check the return value of your zip file access functions (such as extractZip) then your program should be able to properly handle any access violation issues.

04-12-2007

Deb

The c code contains a load dll method. Loads the unzip32.dll

The method I wrote was to call the dll function to extract the zip entries from the specified zip file name.

The return from the dll call is an integer code representing the success/error code.

It works every time when testing and calling the method one file at a time from within the C code... I call the function, it returns, I call the function, it returns....

However, when run on more than one file at a time, calling from JNI -- "it crashes"...

I thought it might have something to do with sending 1 - n calls to the dll function.

From Java calling the native method, the function could get called again before it returns from the last call. Would that matter?

04-13-2007

itsme86

It could if it's not a reentrant function. Functions which have some kind of internal mechanism for keeping track of things in a non-automatic type of way (global or static variable are common) then the second call could corrupt whatever data is in the variable while the first call is using it.

A lot of functions have a reentrant-safe version. For instance, the strtok() function needs to keep track of where it is in the string between calls in order to parse it correctly. If you called strtok() from another thread while the first thread was trying to use it, it would corrupt the internal static buffer. To get around the problem, a lot of environments have a strtok_r() function which accepts a 3rd parameter.

Quote:

char *strtok_r(char *s, const char *delim, char **ptrptr);

The strtok_r() function works the same as the strtok()
function, but instead of using a static buffer it uses a
pointer to a user allocated char* pointer. This pointer,
the ptrptr parameter, must be the same while parsing the
same string.

I don't know if your dll has a similar workaround, but it might be worth looking into.