I have pasted valgrind output, where tesseract is just linked not used any single api of tessearct in my code. then it have following allocation and no free
==5923== 64 bytes in 1 blocks are still reachable in loss record 1 of 5 ==5923== at 0x4C29D90: operator new[](unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==5923== by 0x4FF9AD1: GenericVector<tesseract::StringParam*>::reserve(int) [clone .part.3] (in /usr/local/lib64/libtesseract.so.3.0.4) ==5923== by 0x4EE4132: _GLOBAL__sub_I_drawfx.cpp (in /usr/local/lib64/libtesseract.so.3.0.4) ==5923== by 0x400E929: call_init.part.0 (in /lib64/ld-2.19.so) ==5923== by 0x400EA12: _dl_init (in /lib64/ld-2.19.so) ==5923== by 0x40011C9: ??? (in /lib64/ld-2.19.so) ==5923== ==5923== 128 bytes in 1 blocks are still reachable in loss record 2 of 5 ==5923== at 0x4C29670: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==5923== by 0x509BDE9: GlobalParams() (in /usr/local/lib64/libtesseract.so.3.0.4) ==5923== by 0x4EDCDBF: _GLOBAL__sub_I_baseapi.cpp (in /usr/local/lib64/libtesseract.so.3.0.4) ==5923== by 0x400E929: call_init.part.0 (in /lib64/ld-2.19.so) ==5923== by 0x400EA12: _dl_init (in /lib64/ld-2.19.so) ==5923== by 0x40011C9: ??? (in /lib64/ld-2.19.so) ==5923== ==5923== 512 bytes in 1 blocks are still reachable in loss record 3 of 5 ==5923== at 0x4C29D90: operator new[](unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==5923== by 0x4F29231: GenericVector<tesseract::IntParam*>::reserve(int) [clone .part.47] (in /usr/local/lib64/libtesseract.so.3.0.4) ==5923== by 0x4F2B887: GenericVector<tesseract::IntParam*>::push_back(tesseract::IntParam*) (in /usr/local/lib64/libtesseract.so.3.0.4) ==5923== by 0x4EE0BC6: _GLOBAL__sub_I_makerow.cpp (in /usr/local/lib64/libtesseract.so.3.0.4) ==5923== by 0x400E929: call_init.part.0 (in /lib64/ld-2.19.so) ==5923== by 0x400EA12: _dl_init (in /lib64/ld-2.19.so) ==5923== by 0x40011C9: ??? (in /lib64/ld-2.19.so) ==5923== ==5923== 1,024 bytes in 1 blocks are still reachable in loss record 4 of 5 ==5923== at 0x4C29D90: operator new[](unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==5923== by 0x4F085F1: GenericVector<tesseract::BoolParam*>::reserve(int) [clone .part.74] (in /usr/local/lib64/libtesseract.so.3.0.4) ==5923== by 0x4F0EDB7: GenericVector<tesseract::BoolParam*>::push_back(tesseract::BoolParam*) (in /usr/local/lib64/libtesseract.so.3.0.4) ==5923== by 0x4EE2AA5: _GLOBAL__sub_I_topitch.cpp (in /usr/local/lib64/libtesseract.so.3.0.4) ==5923== by 0x400E929: call_init.part.0 (in /lib64/ld-2.19.so) ==5923== by 0x400EA12: _dl_init (in /lib64/ld-2.19.so) ==5923== by 0x40011C9: ??? (in /lib64/ld-2.19.so) ==5923== ==5923== 1,024 bytes in 1 blocks are still reachable in loss record 5 of 5 ==5923== at 0x4C29D90: operator new[](unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==5923== by 0x4F373B1: GenericVector<tesseract::DoubleParam*>::reserve(int) [clone .part.40] (in /usr/local/lib64/libtesseract.so.3.0.4) ==5923== by 0x4F42B97: GenericVector<tesseract::DoubleParam*>::push_back(tesseract::DoubleParam*) (in /usr/local/lib64/libtesseract.so.3.0.4) ==5923== by 0x4EE5176: _GLOBAL__sub_I_intproto.cpp (in /usr/local/lib64/libtesseract.so.3.0.4) ==5923== by 0x400E929: call_init.part.0 (in /lib64/ld-2.19.so) ==5923== by 0x400EA12: _dl_init (in /lib64/ld-2.19.so) ==5923== by 0x40011C9: ??? (in /lib64/ld-2.19.so) Thanks Anshul On Friday, January 16, 2009 at 6:25:24 PM UTC+5:30, iso8859 wrote: > > Still have the leak > > Remi > > On Jan 15, 11:05 pm, Jesse <[email protected]> wrote: > > I downloaded the latest code changes and compiled it with tessnet2 and > > the memory leak still appears to be there. If someone gets a different > > result please post the tessnet2.dll. > > > > On Jan 15, 11:03 am, "Ray Smith" <[email protected]> wrote: > > > > > Can you test against the latest code in svn? I think the memory leaks > are > > > fixed in there, but I am not sure. (Confused as to what was fixed > when.)Let > > > me know what you find, so I can try to incorporate more fixes from > 3.00 if > > > necessary. > > > Ray. > > > > > On Wed, Jan 14, 2009 at 10:26 AM, Jesse > > > <[email protected]>wrote: > > > > > > > I have been searching for awhile for a semi decent OCR software that > > > > has a .NET interface and was very happy to find tesseract (as well > as > > > > tessnet2) however I have implemented it and I have noticed an > drastic > > > > increased in memory usage after I read about 100 or so images. I > have > > > > been searching throughout the discussions and found that I was not > > > > alone. I was wondering if anyone could tell me whether or not this > is > > > > tessnet2 error or if this is a tesseract error. And of course a way > to > > > > fix it, if possible. > > > > > > I was originally using MODI (M$ Office Document Imaging) to do my > OCR > > > > but the text reading was terrible and it just randomly crashed at > odd > > > > intervals causing the file it was reading at the time to lock up and > > > > thus my program could not overwrite the file for the next pass. -- You received this message because you are subscribed to the Google Groups "tesseract-ocr" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/tesseract-ocr. To view this discussion on the web visit https://groups.google.com/d/msgid/tesseract-ocr/dfa263ae-5abd-4eb3-b528-cef9c541dc6e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
