Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

COMLateBindingObject#getStringProperty leaks memory #867

Closed
matthiasblaesing opened this issue Oct 29, 2017 · 0 comments · Fixed by #869
Closed

COMLateBindingObject#getStringProperty leaks memory #867

matthiasblaesing opened this issue Oct 29, 2017 · 0 comments · Fixed by #869

Comments

@matthiasblaesing
Copy link
Member

In the google group an issue in the COMLateBindingObject#getStringProperty was found:

https://groups.google.com/d/msg/jna-users/jgI3YVbKpRU/LjSMxzH6BAAJ

In my application I have a method to get a string from COM-server, like this:

class MyComProxy extends COMLateBindingObject {
...
public String getData() {
return getStringProperty("my_property");
}
}

When the application run, the Task Manager shows endless growth in memory until the COMException "There was not enough memory to complete the operation" followed by OutOfMemory exception. This occurs about 2GB used memory as showed in the Task Manager. In the same time the java's MissionControl shows the used Heap memory less 256MB.

Next, I change my code to like this:

class MyComProxy extends COMLateBindingObject {
...
public String getData() {
//return getStringProperty("my_property");
String data = createRandomDataString();
return data;
}
}

In this variant the memory stops growth.
So, I think the problem is in the getStringProperty() function.

This was the analysis:

The problem is most probably the handling of Variant in COMLateBindingObject#getStringProperty. Variants that hold strings utilize a BSTR. BSTRs are special in the sense, that they are allocated by SysAllocString and freed by SysFreeString and the memory needs to be explicitly cleared.

For Variants this is handled by VariantClear. VariantClear clears the data contained in the Variant and frees that data (not the Variant itself!). The Variant structure is caller allocated and in JNA located in auto-allocated memory and does not need to be explicitly freed.

matthiasblaesing added a commit to matthiasblaesing/jna that referenced this issue Oct 29, 2017
Variants that hold strings utilize a BSTR. BSTRs are special in the sense, that
they are allocated by SysAllocString and freed by SysFreeString and the memory
needs to be explicitly cleared.

For Variants this is handled by VariantClear. VariantClear clears the data
contained in the Variant and frees that data (not the Variant itself!). The
Variant structure is caller allocated and in JNA located in auto-allocated
memory and does not need to be explicitly freed.

This closes java-native-access#867
matthiasblaesing added a commit to matthiasblaesing/jna that referenced this issue Oct 29, 2017
Variants that hold strings utilize a BSTR. BSTRs are special in the sense, that
they are allocated by SysAllocString and freed by SysFreeString and the memory
needs to be explicitly cleared.

For Variants this is handled by VariantClear. VariantClear clears the data
contained in the Variant and frees that data (not the Variant itself!). The
Variant structure is caller allocated and in JNA located in auto-allocated
memory and does not need to be explicitly freed.

This closes java-native-access#867
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant