jni native method indirect call of shmat returns invalid pointer

[jadrian]

I have a jni native method that calls a function in an existing shared
object library. This
function in the existing shared object library attaches as a client to
an existing shared
memory segment by first calling shmget with with a key acquired from a
file through a
separate library function call, a size of zero and permissions of user
and group read/write.

At this point everything is fine. Debugging the code as called from
the jni native method
matches the same code as called from a regular c shared object library
function call for
each parameter and both return the same identifier from the call to
shmget. The two
approaches diverge only after a call to shmat, which is made with the
identifier returned
from shmget as shmid and a value of zero for both the addr and flag
parameters.

Called from a c program, shmat returns a pointer to address
0x40000000, which is correct.

Called from the jni native method, shmat returns a pointer to address
0xc0000000, which
appears to be somewhere in the shared memory area, based on an
examination of bytes after the 0xc0000000 address, but not the correct
start of the shared memory segment sought.

The exact same call is made to shmat with the exactly same parameters
(11,0,0) but,
depending on whether the call to this function is made from the native
method or from a
plain vanilla c shared object library function, a different address is
returned from shmat.

AIX 5.3, 64-bit kernel, applications run 32-bit, java ver 1.5.

The key here is that the jni native method calls the existing shared
object library fine up
to and including the call to shmget; it only stumbles on the call to
shmat and doesn't
error, it just returns an inaccurate pointer. Stevens' APUE (p.466)
says:

"If addr is 0, the segment is attached at the first available address
selected by the
kernel. This is the recommended technique."

This doesn't answer the question but might be the point to focus on.

Any ideas or suggestions would be welcome. I'm stumped.

 

[Gordon Beaton]

Called from a c program, shmat returns a pointer to address
0x40000000, which is correct.

Called from the jni native method, shmat returns a pointer to
address 0xc0000000, which appears to be somewhere in the shared
memory area, based on an examination of bytes after the 0xc0000000
address, but not the correct start of the shared memory segment
sought.

In almost most cases you should specify NULL with shmat() to let the
system choose an appropriate free address to attach the region. A
given segment will usually *not* attach at the same address in
different programs.

If you are already specifying NULL to attach the segment, forget the
idea that one particular address is the correct one. If not, try doing
so.

Have you tried specifying the correct segment size (not 0) in
shmget()?

While your program is running, use ipcs to see whether the segment is
attached to any processes. Use a tool like pmap <pid> to see the
current mappings for your process, or look in the process file system
to get the information.

Without seeing code, there isn't much more to say here. However there
is nothing inherently magic about using shmat() from JNI, I've done it
myself without any problems. I suspect your problems aren't related to
JNI per se, and suggest that an AIX group might be a more appropriate
place for this.

/gordon

--

 

[jadrian]

Without seeing code, there isn't much more to say here. However there

is nothing inherently magic about using shmat() from JNI, I've done it
myself without any problems. I suspect your problems aren't related to
JNI per se, and suggest that an AIX group might be a more appropriate
place for this.

Hello Gordon,

Thanks again for your help and I have posted to comp.unix.aix as
well. I think the difference here is that the call to shmget and
shmat is not being made directly from the native library but instead
the native library is linking into an existing shared object library
which has wrapper functions to handle all the shared memory functions.

I understand that this pointer exists in the calling process space.
What I should have said is that the memory location this pointer
points to differs from when it is called from a c shared object
library function than from when it is called from the jni native
method, where ss is a char pointer that the void pointer shmat returns
is cast to:

(from c) &ss[0] == 0x40000000
(from native method) &ss[0] == 0xc0000000

My understanding is that both pointers should be pointing to the same
address, i.e. the specific location of that particular memory segment.

There was one reference I found that I thought might be relevant:
http://groups.google.com/group/comp...&q=java+jni+shmat+aix&rnum=1#06d7f634fccadeb5

.... but at this point I don't think that that is the problem.
Possibly a 64/32 bit issue? I don't think it's that either--the
kernel is 64-bit but the compiler is 32-bit for everything, at least
on the c side.

I think that the problem is derived ultimately from the fact that the
main process is java. By the way, my original problem with being able
to load the existing shared object library with the extern variables
turned out to be that the .imp file for the existing .so library
needed
#!.. (pound exclaim dot dot)
.... on the first line instead of
#!. (pound exclaim dot)

The ld man page says the first form tells the linker to resolve
externs from the main module, the second form tells the linker to just
find them wherever, so you were right about it being a linking issue
rather than variable declaration syntax.

I'll try your suggestions to see if they lead anywhere and if you
think of anything else please let me know.

Thanks again.

Jeff

==================================