Skip to content
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

It seems to have some memory leak in vs2013 #119

Closed
aricatamoy opened this issue Nov 18, 2015 · 4 comments
Closed

It seems to have some memory leak in vs2013 #119

aricatamoy opened this issue Nov 18, 2015 · 4 comments
Assignees

Comments

@aricatamoy
Copy link

I use log4cplus-master in my project, and use

_CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) | _CRTDBG_LEAK_CHECK_DF);

to check whether it exists memory leak.

@wilx
Copy link
Contributor

wilx commented Nov 18, 2015

I have recently fixed a leak in loggingserver. Is that it?

If it is different leak, what is your configuration? How do you use log4cplus? How do I reproduce the leak? How big is the leak? Please provide some details.

@wilx wilx self-assigned this Nov 18, 2015
@aricatamoy
Copy link
Author

The code is here:

#include "log4cplus/initializer.h"

int main(int argc, char *argv[])
{
    _CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) | _CRTDBG_LEAK_CHECK_DF);
    log4cplus::Initializer test_initializer;
    return 0;
}

I use log4cplus-master, edit the *.vcxproj file, replace "v140" to "v120" to compile it in my vs2013. It reports memory leaks. It's possibly cause by stringhel

Here is the output:

Detected memory leaks!
Dumping objects ->
{1428} normal block at 0x004D7778, 32 bytes long.
 Data: <..\src\stringhel> 2E 2E 5C 73 72 63 5C 73 74 72 69 6E 67 68 65 6C 
{1427} normal block at 0x004D7730, 8 bytes long.
...

@wilx
Copy link
Contributor

wilx commented Nov 19, 2015

Leaks like this have been reported few times already. Unless this leak actually accumulates during longer run time, I do not think it is an issue. I think the problem is that the leaks reporting routine runs before the memory is actually deallocated. There is some thread-local storage that gets freed only at the very end of threads execution or process execution.

@aricatamoy
Copy link
Author

ok, thank you very much.

@wilx wilx closed this as completed Nov 19, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants