On May 23, 2008, at 3:32 AM, Thomas Börkel wrote:
Here you are freeing native memory without first clearing the Java
object which references it. "displayGroup" is depending on the
sortedBuf pointer value. You should set displayGroup/displayGroups
to null prior to freeing the native memory.
I do not understand quite what that would accomplish. This does not
mean that the GC removes the object immediately and on the other
hand, I am not using it anymore after freeing it.
In your posted code, it wouldn't have any effect other than to ensure
that the Java object cannot be accessed. You can never tell what
someone's omitted from posted code, though.
Or do I have to make a COPY of displayGroup.grpi3_name for storing
in my own TreeSet domainGroups?
Java Strings are independent of the underlying native memory, so once
the string is copied, the native memory may be disposed safely.
In the meantime, I discovered (by attaching WinDbg to other Java
programs, like SwingSet2), that unhandled access violation seem to
be normal in Java applications!
Perhaps the VM does some structured exception handling to catch
expected access violations?
The heap corruption, that I got in my application is now gone, after
I changed another function:
Glad to hear it. Can you summarize the issue (I don't think many
folks would be able to glean the essential difference from reading the
w32 API code...)? Perhaps something to be included in a FAQ for
things to watch out for?
7 messages in net.java.dev.jna.usersRe: [jna-users] Finding Access violat...
