IOException in MappedByteBuffer.force0

[Me]

Hello,

i have an IOException without any message when calling fore() on a
MappedByteBuffer. Is there a way to see the source code of the native
method force0? Or does anybody knows what can be the cause of this
exception?

Caused by: java.io.IOException
at java.nio.MappedByteBuffer.force0(Native Method)
at java.nio.MappedByteBuffer.force(MappedByteBuffer.java:144)

On a Windows XP Pro (2002) SP2, with JDK 1.5.0_10 or 1.6.0

Thanks in advance

 

[Tom Hawtin]

i have an IOException without any message when calling fore() on a
MappedByteBuffer. Is there a way to see the source code of the native
method force0? Or does anybody knows what can be the cause of this
exception?

For Windows, the source code is in:

j2se/src/windows/native/java/nio/MappedByteBuffer.c

Depending upon the version you want, it can be downloaded from:

https://jdk6.dev.java.net/
https://jdk7.dev.java.net/
https://tiger.dev.java.net/

Tom Hawtin

 

[Paul Davis]

Hello,

i have an IOException without any message when calling fore() on a
MappedByteBuffer. Is there a way to see the source code of the native

You could download it from Sun

method force0? Or does anybody knows what can be the cause of this
exception?

If might be hard to find the source of the exception without your
code...

 

[Gordon Beaton]

Caused by: java.io.IOException
at java.nio.MappedByteBuffer.force0(Native Method)
at java.nio.MappedByteBuffer.force(MappedByteBuffer.java:144)

On a Windows XP Pro (2002) SP2, with JDK 1.5.0_10 or 1.6.0

On Windows, it means that FlushViewOfFile(addr, len) returned 0.

Consult your system documentation for details (I don't know more than
this).

/gordon

 

[Me]

Gordon Beaton a écrit :

On Windows, it means that FlushViewOfFile(addr, len) returned 0.

Thanks to all of you.

According to :
http://msdn2.microsoft.com/en-us/library/aa366563.aspx

i need the value from getLastError(), which is not called from the
native method. I don't think i'm able to build a modified version of the
JDK...

 

[Gordon Beaton]

According to :
http://msdn2.microsoft.com/en-us/library/aa366563.aspx

i need the value from getLastError(), which is not called from the
native method. I don't think i'm able to build a modified version of
the JDK...

Perhaps not, but it shouldn't be necessary either. Write a class of
your own with a static native method from which you call
getLastError(). Call your method from the catch block when the
exception occurs.

/gordon

 

[Lew]

shudder!

Pretty much a guarantee that if your problem analysis leads you to think about
rewriting the JDK, or any part thereof (not clear which part of the JDK was
deemed deficient - it's a big world), that it's time to back up and go down a
different path in that analysis.

- Lew

 

[Florian Weimer]

* Gordon Beaton:

Perhaps not, but it shouldn't be necessary either. Write a class of
your own with a static native method from which you call
getLastError(). Call your method from the catch block when the
exception occurs.

Doesn't this assume that the handler runs in the same OS thread as the
previous native call, and that no other Windows API call is made
in-between? I think neither is guaranteed.

 

[Gordon Beaton]

Doesn't this assume that the handler runs in the same OS thread as
the previous native call, and that no other Windows API call is made
in-between? I think neither is guaranteed.

My understanding is that the catch block must in the same thread as
the corresponding try block. A simple test (checking Thread.getId())
seems to confirm that this is the case. Perhaps it's documented
somewhere, I haven't checked.

Also, most Windows functions that set "last error" only set it when
they fail, so an intervening API call does not necessarily mean that
the source of the error will be lost. I realize that this isn't
guaranteed (some functions set last error to 0 when they succeed), but
if the error itself is repeatable and the code path from exception to
test is reasonably short, then there is a good chance that you can
catch the source of the error in a short debugging session.

/gordon

 

[Florian Weimer]

* Gordon Beaton:

My understanding is that the catch block must in the same thread as
the corresponding try block. A simple test (checking Thread.getId())
seems to confirm that this is the case. Perhaps it's documented
somewhere, I haven't checked.

I'm concerned that the JVM might map multiple Java threads to the same
OS thread (or different Java threads to a single OS thread).
Obviously, Thread.getId() will hide such things, gut the GetLastError
call might still give wrong results.