«

Hello,

I am trying to use JNI to access a C function that processes some data
in a byte[] and returns a new byte[]. I get the following error:

Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred
at PC=0x807A126
Function=[Unknown.]
Library=C:\J2SDK1~1.2_0\jre\bin\client\jvm.dll

NOTE: We are unable to locate the function name symbol for the error
just occurred. Please refer to release documentation for
possible
reason and solutions.


Since the function is unknown and it's in the jvm.dll, how can I
figure out what the problem is? I know that generally this type of
error is pointer-related, but how can I track it down? I don't see
anything in the release documentation to help me out here. I have seen
other people with this type of problem, but usually the error occurs
in their native code. This one is in the jvm.dll. Here is my JNI
function:

JNIEXPORT jbyteArray JNICALL Java_testpkg_test(JNIEnv *jnienv, jobject
jobj, jbyteArray data)
{
// Get C variables
int arraySize = jnienv->GetArrayLength(data);
int outputSize;
unsigned char *arrayBytes = (unsigned char *)
jnienv->GetByteArrayElements(data, 0);

// process the array
unsigned char *processedData = processData(arrayBytes, arraySize,
&outputSize);

//create java array with processed data
jbyteArray returnedArray = jnienv->NewByteArray(outputSize);
jnienv->SetByteArrayRegion(returnedArray, 0, outputSize, (signed
char *) processedData);

//release the byte array to the JVM
jnienv->ReleaseByteArrayElements(data, (signed char *)arrayBytes ,
0);

return(returnedArray);
}

Much thanks in advance for any help.

From microsoft.com (maybe you can search yourself sometime)
----------------------------------------------------------
Many exception errors are not processed by applications. The most common
exception error is EXCEPTION_ACCESS_VIOLATION (c0000005). It occurs when a
pointer is dereferenced and the pointer points to inaccessible memory or a
write operation is attempted on read-only memory. If an application does not
trap an exception, the Win32 module, UnhandledExceptionFilter, will do one
of the following: display a message box, invoke Dr. Watson, or attach your
application to a debugger.
----------------------------------------------------------


"Doug Trammell" <> wrote in message
news: om...
> Hello,
>
> I am trying to use JNI to access a C function that processes some data
> in a byte[] and returns a new byte[]. I get the following error:
>
> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred
> at PC=0x807A126
> Function=[Unknown.]
> Library=C:\J2SDK1~1.2_0\jre\bin\client\jvm.dll
>
> NOTE: We are unable to locate the function name symbol for the error
> just occurred. Please refer to release documentation for
> possible
> reason and solutions.
>
>
> Since the function is unknown and it's in the jvm.dll, how can I
> figure out what the problem is? I know that generally this type of
> error is pointer-related, but how can I track it down? I don't see
> anything in the release documentation to help me out here. I have seen
> other people with this type of problem, but usually the error occurs
> in their native code. This one is in the jvm.dll. Here is my JNI
> function:
>
> JNIEXPORT jbyteArray JNICALL Java_testpkg_test(JNIEnv *jnienv, jobject
> jobj, jbyteArray data)
> {
> // Get C variables
> int arraySize = jnienv->GetArrayLength(data);
> int outputSize;
> unsigned char *arrayBytes = (unsigned char *)
> jnienv->GetByteArrayElements(data, 0);
>
> // process the array
> unsigned char *processedData = processData(arrayBytes, arraySize,
> &outputSize);
>
> //create java array with processed data
> jbyteArray returnedArray = jnienv->NewByteArray(outputSize);
> jnienv->SetByteArrayRegion(returnedArray, 0, outputSize, (signed
> char *) processedData);
>
> //release the byte array to the JVM
> jnienv->ReleaseByteArrayElements(data, (signed char *)arrayBytes ,
> 0);
>
> return(returnedArray);
> }
>
> Much thanks in advance for any help.

Doug Trammell wrote:

> Since the function is unknown and it's in the jvm.dll, how can I
> figure out what the problem is? I know that generally this type of
> error is pointer-related, but how can I track it down?

Nothing leaps out at me that's wrong with your JNI code.

There's isn't a magic bullet for these problems -- or if there is, then I've
wasted a lot of my own time by not knowing about it...

If I were in this position, I'd continue cutting down the example until the
problem went away. (I'm assuming from the look of your example that you've
already cut it down a lot). For example, can you make the problem go away by
dummying-out the call to processData() ? That and add lots and lots of
logging...

Oh, I'd also double- and triple-check that I wasn't holding onto jobject (or
similar) referenvces, and review how I was using threads.

Not a lot of help, I'm afraid, but after the response from that twit "nos", I
thought maybe you could use a little encouragement

-- chris

Thanks for the reply Chris. I'll keep narrowing it down...

It seems unusual that the exception would come from jvm.dll and not mine though.

"Chris Uppal" <> wrote in message news:<mY2dnfjhxZjXQ9vdRVn->...
> Doug Trammell wrote:
>
> > Since the function is unknown and it's in the jvm.dll, how can I
> > figure out what the problem is? I know that generally this type of
> > error is pointer-related, but how can I track it down?
>
> Nothing leaps out at me that's wrong with your JNI code.
>
> There's isn't a magic bullet for these problems -- or if there is, then I've
> wasted a lot of my own time by not knowing about it...
>
> If I were in this position, I'd continue cutting down the example until the
> problem went away. (I'm assuming from the look of your example that you've
> already cut it down a lot). For example, can you make the problem go away by
> dummying-out the call to processData() ? That and add lots and lots of
> logging...
>
> Oh, I'd also double- and triple-check that I wasn't holding onto jobject (or
> similar) referenvces, and review how I was using threads.
>
> Not a lot of help, I'm afraid, but after the response from that twit "nos", I
> thought maybe you could use a little encouragement
>
> -- chris

It was the call to SetByteArrayRegion that was causing the exception.
It turns out that any access to the buffer returned from processData()
would cause that same exception, so I tracked it down in
processData(). The pointer was being returned from a COM object and I
had to copy the data into a separate buffer before returning it. Then
SetByteArrayRegion worked fine. Not sure what the COM problem is
since I'm no expert there, but it's now off-topic for this group.
Thanks for the help Chris.

- Doug

"Chris Uppal" <> wrote in message news:<mY2dnfjhxZjXQ9vdRVn->...
> Doug Trammell wrote:
>
> > Since the function is unknown and it's in the jvm.dll, how can I
> > figure out what the problem is? I know that generally this type of
> > error is pointer-related, but how can I track it down?
>
> Nothing leaps out at me that's wrong with your JNI code.
>
> There's isn't a magic bullet for these problems -- or if there is, then I've
> wasted a lot of my own time by not knowing about it...
>
> If I were in this position, I'd continue cutting down the example until the
> problem went away. (I'm assuming from the look of your example that you've
> already cut it down a lot). For example, can you make the problem go away by
> dummying-out the call to processData() ? That and add lots and lots of
> logging...
>
> Oh, I'd also double- and triple-check that I wasn't holding onto jobject (or
> similar) referenvces, and review how I was using threads.
>
> Not a lot of help, I'm afraid, but after the response from that twit "nos", I
> thought maybe you could use a little encouragement
>
> -- chris

Doug Trammell wrote:

> It turns out that any access to the buffer returned from processData()
> would cause that same exception, so I tracked it down in
> processData(). The pointer was being returned from a COM object and I
> had to copy the data into a separate buffer before returning it.

Aha! Glad you found a fix. Thanks for letting us know how it turned out.


> Not sure what the COM problem is
> since I'm no expert there,

I am pleased... no, that's not right... I am *proud* to say that neither am I.

-- chris