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

[BridJ] Memory leak in VARIANT even in basic use? #389

Closed
ErwinBellon opened this Issue Mar 21, 2013 · 4 comments

Comments

Projects
None yet
2 participants
@ErwinBellon

ErwinBellon commented Mar 21, 2013

I am looking for memory leaks in a COM application using an own IMallocSpy implementation (difficult to isolate in a small test application) and suspect VARIANT to leak.

If I track following code:

Pointer pVariant = allocate(VARIANT.class);
pVariant.get().setValue("some string");
pVariant.release();

I get following information about the creation of a memory block that subsequently was never freed:

Memory block at address xxx size16 [size is 16 independent from which string was inserted]
org.bridj.cpp.com.OLEAutomationLibrary.VariantChangeType(Native Method) -2
org.bridj.cpp.com.COMRuntime.change(COMRuntime.java:358) 358
org.bridj.cpp.com.COMRuntime.setValue(COMRuntime.java:389) 389
org.bridj.cpp.com.VARIANT.setValue(VARIANT.java:1119) 1119

I should be using BridJ 6.0.2 on a Windows 7 64 bits OS but in a 32 bit Java environment.

Any hint on how to better use VARIANT was welcome - maybe I should call some other method to properly release the memory. I actually just use VARIANT to get a string from a property bag.

Thanks,

Erwin

@ochafik

This comment has been minimized.

Show comment
Hide comment
@ochafik

ochafik Mar 24, 2013

Member

Hi @ErwinBellon ,

Thanks for your report.
Your code snippet seems okay, roughy equivalent (but a tiny bit slower) to:

VARIANT variant = new VARIANT("some string");
...
BridJ.delete(variant);

Out of curiosity, which tool did you use to get this information about the leak? (I'm planning a Windows coding / testing session soon, would be cool if I could investigate this then :-))

Cheers

Member

ochafik commented Mar 24, 2013

Hi @ErwinBellon ,

Thanks for your report.
Your code snippet seems okay, roughy equivalent (but a tiny bit slower) to:

VARIANT variant = new VARIANT("some string");
...
BridJ.delete(variant);

Out of curiosity, which tool did you use to get this information about the leak? (I'm planning a Windows coding / testing session soon, would be cool if I could investigate this then :-))

Cheers

@ErwinBellon

This comment has been minimized.

Show comment
Hide comment
@ErwinBellon

ErwinBellon Mar 24, 2013

Dear Oliver,

Thanks for answering.

By the way, if I just found out that if call VariantClear() defined in OleAut32 (using the BridJ-tricks) I do not have the leak anymore. But I would have expected that to be covered already within your VARIANT class.

I implemented a simplistic IMallocSpy. I originally tried to do that completely in Java using BridJ but my knowledge was insufficient for that. I ended up creating a small dll in native code that is supplied the callbacks to be invoked at Java side. For what it is worth I include the unpolished native project and the as dirty Java side bindings. In my test application I keep track of allocated memory info with stack traces in some simple data structures of which the entries are cleared when the spy signals that the memory at the corresponding address gets freed.

I have the impression that the system sometimes caches information after first use anyhow, so there will often be some apparent leaks. OleAut32.SetOaNoCache() should be called to prevent caching of B-strings, but I suspect that is not sufficient. (Or I may have actual leaks after all).

In my (dirty – I apologize again) native code there are some lines for obtaining the JVM or the Env pointer from native code because I had not found out BridJ can already give me that. And the java spy class contains some code to force GC using JVMTI, but I believe I gate that to the native dll. That probably could also have been done completely in Java with BridJ.

Erwin

From: Olivier Chafik [mailto:notifications@github.com]
Sent: zondag 24 maart 2013 15:14
To: ochafik/nativelibs4java
Cc: Erwin Bellon
Subject: Re: [nativelibs4java] [BridJ] Memory leak in VARIANT even in basic use? (#389)

Hi @ErwinBellonhttps://github.com/ErwinBellon ,

Thanks for your report.
Your code snippet seems okay, roughy equivalent (but a tiny bit slower) to:

VARIANT variant = new VARIANT("some string");

...

BridJ.delete(variant);

Out of curiosity, which tool did you use to get this information about the leak? (I'm planning a Windows coding / testing session soon, would be cool if I could investigate this then :-))

Cheers


Reply to this email directly or view it on GitHubhttps://github.com/nativelibs4java/nativelibs4java/issues/389#issuecomment-15359545.

ErwinBellon commented Mar 24, 2013

Dear Oliver,

Thanks for answering.

By the way, if I just found out that if call VariantClear() defined in OleAut32 (using the BridJ-tricks) I do not have the leak anymore. But I would have expected that to be covered already within your VARIANT class.

I implemented a simplistic IMallocSpy. I originally tried to do that completely in Java using BridJ but my knowledge was insufficient for that. I ended up creating a small dll in native code that is supplied the callbacks to be invoked at Java side. For what it is worth I include the unpolished native project and the as dirty Java side bindings. In my test application I keep track of allocated memory info with stack traces in some simple data structures of which the entries are cleared when the spy signals that the memory at the corresponding address gets freed.

I have the impression that the system sometimes caches information after first use anyhow, so there will often be some apparent leaks. OleAut32.SetOaNoCache() should be called to prevent caching of B-strings, but I suspect that is not sufficient. (Or I may have actual leaks after all).

In my (dirty – I apologize again) native code there are some lines for obtaining the JVM or the Env pointer from native code because I had not found out BridJ can already give me that. And the java spy class contains some code to force GC using JVMTI, but I believe I gate that to the native dll. That probably could also have been done completely in Java with BridJ.

Erwin

From: Olivier Chafik [mailto:notifications@github.com]
Sent: zondag 24 maart 2013 15:14
To: ochafik/nativelibs4java
Cc: Erwin Bellon
Subject: Re: [nativelibs4java] [BridJ] Memory leak in VARIANT even in basic use? (#389)

Hi @ErwinBellonhttps://github.com/ErwinBellon ,

Thanks for your report.
Your code snippet seems okay, roughy equivalent (but a tiny bit slower) to:

VARIANT variant = new VARIANT("some string");

...

BridJ.delete(variant);

Out of curiosity, which tool did you use to get this information about the leak? (I'm planning a Windows coding / testing session soon, would be cool if I could investigate this then :-))

Cheers


Reply to this email directly or view it on GitHubhttps://github.com/nativelibs4java/nativelibs4java/issues/389#issuecomment-15359545.

@ochafik

This comment has been minimized.

Show comment
Hide comment
@ochafik

ochafik Mar 24, 2013

Member

Hi Erwin,

Thanks a lot for these interesting details, I didn't know about IMallocSpy!
It seems github has swallowed your attachment, can you try an alternative method? (link to file on Drive here, or direct email to olivier.chafik@gmail.com ?)

Cheers

Member

ochafik commented Mar 24, 2013

Hi Erwin,

Thanks a lot for these interesting details, I didn't know about IMallocSpy!
It seems github has swallowed your attachment, can you try an alternative method? (link to file on Drive here, or direct email to olivier.chafik@gmail.com ?)

Cheers

ochafik added a commit that referenced this issue Mar 24, 2013

BridJ/COM: use VariantInit and VariantClear for proper VARIANT manage…
…ment, + allocate it (and other structs tagged with COMRuntime) with CoTaskMemAlloc (see issue #389)
@ochafik

This comment has been minimized.

Show comment
Hide comment
@ochafik

ochafik Mar 18, 2015

Member

This issue was moved to nativelibs4java/BridJ#26

Member

ochafik commented Mar 18, 2015

This issue was moved to nativelibs4java/BridJ#26

@ochafik ochafik closed this Mar 18, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment