You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 closesjava-native-access#867
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 closesjava-native-access#867
In the google group an issue in the
COMLateBindingObject#getStringProperty
was found:https://groups.google.com/d/msg/jna-users/jgI3YVbKpRU/LjSMxzH6BAAJ
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.
The text was updated successfully, but these errors were encountered: