Memory leak detection

[mrusu]

Would be useful to have a memory leak detection option, especially combined with systemtest.

[mrusu]

Reopened the ticket, since it refers to something else than ../systemtest/testcases_fixed/test_memleak
As I could see, test_memleak checks for errors 801 (system overload) or 206 (error in base dbms), but not for memory leaks caused by the code, when the allocated memory is not freed afterwards. I am sure there are quite a number of occurrences.

[abeccati]

Thanks Mihaela, Would you please add a little more detail on the description about what should be done to solve this (e.g. use a code analysis tool or else).

Do we already have relevant consequences on that or will the servers restart (countdown) take care of cleaning them? In the latter case I think we can move this to "Future" milestone with minor priority.

Alan

[Dimitar Misev]

I assume the test should run valgrind or similar on directql (not rasql, valgrind can't be attached to server processes), and automatically extract from the valgrind output whether there is a memleak or not.

Server restart can fix memleaks, but sometimes, e.g. nasty memleak during import or a million queries between restarts it can be fatal.

[Dimitar Misev]

I put it for 8.5 but Jin can reassign this to someone else or different milestone, he's the owner of systemtest after all.

[Jinsongdi Yu]

the Makefile in systemtest should know —enable-debug and run the test.sh if the debug is on

[Dimitar Misev]

What should it know?

[Jinsongdi Yu]

the ./configure —enable-debug
with will set RMANDEBUG=on, CXXFLAGS+=" -g3 -gdwarf-2 -O0 "
test queries can be fetched from ../systemtest/testcases_mandatory/test_select/test_rasql/

[Dimitar Misev]

We could try to write a C++ client directly integrated in the server in the style of directql or source:relblobif/test/test_tilecache.cc which would run all the queries in source:systemtest/testcases_mandatory, and run this through valgrind.

[Dimitar Misev]

duplicate #919