-
Notifications
You must be signed in to change notification settings - Fork 14
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
Did you observe a severe memory leak when using Leptonica? #2
Comments
Which version are you using of leptonica, os, jdk? |
Make sure you call relevant |
I am using lept1.2.3. There are no xxxDestroy() method. Where can I find it? Here is part of my code:
There are no pix1.Destroy() or pix2.Destroy() function. |
|
@nguyenq Sorry, where did it locate? I cannot see it in the document link. |
@nguyenq I found an example in the repo about pixDestroy. But, i performed that and there is still memory leak. In fact, after doing pixDestroy(pix1), I checked and found that pix1 is not null.
|
The example mirrors the original c example. |
@nguyenq I am running the code in a for-loop. So, I suppose after each iteration the java garbage collector recollect the memory. But, in my case, the memory usage is keep stacking up even I do pixDestroy(). Are you suggesting I should explicitly do System.gc() to force the Java Garbage Collector to check and it may do something?
|
I think I found the problem. It is a bit tricky to use leptInstance. IN the below code, I have pix2 be reassigned twice. Normally, in Java, this is fine and the garbage collector will know to collect the original object of pix2 (from the first assigment). However, in leptInstance, the original first object of pix2 will be kept somewhere in the memory. Therefore, what I should do is to instead assign a new variable to take the second assignment of pix2, i.e.. Original code with memory leak
What I should change is this:
|
Although the above problem is solved, but when I call convertPixToImage(pix3) in a for-loop, there is severe memory leak again. I am pretty sure I pixDestroy(Pix3), so the problem is probably not related to pix3
I think it is a bug because in C++ code, we need to free the memory of "data" explicitly, which in the lept4j java version I cannot find a function to do that. According to this example:
|
Yes, that seems to be the C-language standard practice of having separate variables to hold objects and subsequent destroying of these objects after use. That's why you see many separate instances of |
@nguyenq So, is there any way to solve the problem that I have when we are using pixWriteMem? |
@nguyenq I guess we may have to request function add to C code of leptonica to free certain memory? |
@johnny5550822, can you narrow down to the line and function where memory may not get released? Is it in |
@nguyenq In this line, the memory of pdata is not freed, which you need to free explicitly in C code (as shown in above comment.) I have already post an error on their github page, but seem like no one take care of it. :( |
You may want to search through Lept4J's Or search JNA API for any method that can free a byte array. |
@nguyenq I have searched, but cannot find anything about it. Do you? |
@nguyenq is this problem being resolved? |
Hey @johnny5550822 @nguyenq assigned this issue to me by email. Deal? |
@4F2E4A2E Sound good to me. I will create a sample Junit test, and then submit a pull request. Where should this test code go to? |
Best thing would be a pull request, else gist, else if all fails as a comment. |
Sure. I will do a pull request then. @4F2E4A2E Sorry for delay, I will try to submit pull request as soon as I can. I have been busy for my work. |
@johnny5550822 A fix has been committed. Please check it out. |
@nguyenq Awesome! I will try that out. Thanks. |
I observed there is severe memory leak when I am using Leptonica, did you observe that? I tried explicitly calling System.gc() or using JNA Memory.disposeAll(). None of this work. So, I am guess there is memory leak issue when using lept4J.
The text was updated successfully, but these errors were encountered: