gdcarver
commented
1 year ago Relates to #11.
Closed gdcarver closed 1 year ago
gdcarver
commented
1 year ago Relates to #11.
gdcarver
commented
1 year ago Bugs fixed:
1/ process_trickle function leak
New char[ ] was created with 'new' (heap memory), but never deleted.
char* trickle = new char[512];
Added:
delete [] trickle;
2/ Leaks from use of regex
regcomp creates internal data structures which must be explicitly freed. This code was causing the problems:
while ((dir=readdir(dirp)) != NULL ) {
regcomp(®ex,”^[ICM+]”,0);
regcomp(®ex,”\\+”,0);
if (!regexec(....))....Several issues here: 1/ the 2nd regcomp replaces the 1st meaning memory from 1st call is lost. 2/ both the regcomp’s are in the while loop and repeatedly create new data structures, accumulating more leaks. 3/ no referee is used to free regcomp memory.
Fixes: 1/ delete the first unused regcomp. 2/ move the regcomp outside the while loop - only need to compile the regex once. 3/ add in a refree after the while loop.
gdcarver
commented
1 year ago Leaks from boinc_zip(). It's clear from the trace there's alot of leaks from the use of boinc_zip.
Checked the calls and found that several calls to boinc_zip were not using the right type, the upload filepath was passed as a char [ ] rather than std::string as defined in the header. Although this works, it means the compiler will do a copy into a string. It's possible this might be causing memory leaks further down the calling tree.
Have changed:
retval = boinc_zip(ZIP_IT,upload_file,&zfl);
to
std::string upfile("");
...
upfile = string(upload_file);
retval = boinc_zip(ZIP_IT,upfile,&zfl); // n.b. pass std::string to avoid copy-on-call
upfile.clear();This works ok but still seeing leaks reported by Asan.
If I add a 'return 1' directly after the very first call to boinc_zip() for unzipping the app zipfile then I get the first leak:
=================================================================
==1552==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 255 byte(s) in 1 object(s) allocated from:
#0 0x7fd6a6b5ea06 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:153
#1 0x7fd6a698c6ee in boinc_zip(int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const*) (/home/glenn/github/boinc-install/lib/libboinc_zip.so.7+0x116ee)
SUMMARY: AddressSanitizer: 255 byte(s) leaked in 1 allocation(s).255 bytes suggests a possible pointer being lost? Tried a couple of things but was unable to get around this leak in the controller code.
Am not sure if the problem is with the way the control code is calling the function boinc_zip() or with boinc_zip itself. It will take more work to determine this.
Will split this issue and create separate one for boinc_zip() and look at it later, after CPDN have assessed the reduction in memory errors from these changes.
gdcarver
commented
1 year ago Current crop of leaks is fixed - leaks in boinc_zip split into new issue.
Leak analysis with Google address sanitizer revealed no. of memory leaks, likely responsible for the double corruption/free() errors we see in some of the tasks.
Compiling with: -fsanitize=address -ggdb3
produced following leak report: