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.