zeusdeux / re2

Automatically exported from code.google.com/p/re2
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

Memory leaks in RE2::RE2 objects #84

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Simply creating a RE2 object as stated in the documentation creates a memory 
leak:
RE2 matchingRegexBegin("([a-zA-Z]+)");

This happens only on the first creation of a RE2 object, further objects dont 
create further leaks.

I pastebinned the leaks, although they are not specifically helpful, other than 
for knowing the respective size of the leaked chunks:

http://pastebin.com/wpeucBH7

I tried to figure what kind of one-time initialisation could cause this but the 
constructor is quite complicated and lacks overview. I assume it could be 
related to mutexes but i dont know.

Note: I use the latest version of the code via the windows port, but i think 
this shouldn't be the cause of the leak:
http://code.google.com/p/re2win/

Original issue reported on code.google.com by kukid...@gmx.at on 16 Jun 2013 at 2:32

GoogleCodeExporter commented 9 years ago
For what it's worth, I'm not aware of any leaks in the standard (non-Windows) 
version of RE2. We run with lots of leak checking at Google.

Without more information about the purported leak, there's not much I can do.

Original comment by rsc@golang.org on 21 Jun 2013 at 4:32

GoogleCodeExporter commented 9 years ago
I have no access to a good memory leak tracking tool at the moment so I can't 
give more information right now. The next 4 weeks I will be busy but after that 
I will try to find a good tool and give more info

Original comment by kukid...@gmx.at on 21 Jun 2013 at 6:03

GoogleCodeExporter commented 9 years ago
Hi,

 Most likely this is related to static variables used by the lib. E.g. check out re2.c
GLOBAL_MUTEX(empty_mutex);
static const string *empty_string;
static const map<string, int> *empty_named_groups;
static const map<int, string> *empty_group_names;

So these guys will try to get some memory from the heap and delete after a 
return from main.

Most likely you are used some sort of default CRT heap checker. Maybe you could 
play with flags: _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF 
) in the first place and also check the addresses that "leaked".

Original comment by DenisKra...@gmail.com on 2 Jul 2013 at 2:24

GoogleCodeExporter commented 9 years ago

Original comment by rsc@golang.org on 10 Jan 2014 at 1:32