> It would be nice if Make cleaned up its resources before exiting. Would it? Linking all those blocks back on to free lists and coalescing adjacent ones doesn't take a long time but it takes more time than just tearing down the address space. It can be a reasonable economy for short-lived processes not to clean up before exiting. Recursive make might be considered harmful but it's still a common use-case with such short-lived processes.
> It looks like Make's memory leaks are killing the build process long before > the test runners execute. I presume you have some compelling evidence for that and I appreciate not being deluged with large attachments... but the trouble with what you have shared is that 89 bytes leaked in total seems like it wouldn't be a problem for even the smallest system. ________________________________ From: Bug-make <bug-make-bounces+martin.dorey=hds....@gnu.org> on behalf of Jeffrey Walton <noloa...@gmail.com> Sent: Tuesday, May 14, 2019 19:19 To: bug-make@gnu.org Subject: Memory leaks in Make ***** EXTERNAL EMAIL ***** Hi Everyone, My apologies if I raised this issue already. I did not see it in the archives at https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnu.org%2Farchive%2Fhtml%2Fbug-make%2F2019-04%2Findex.html&data=01%7C01%7CMartin.Dorey%40hitachivantara.com%7C5aed86365df54e159bc208d6d8dbb855%7C18791e1761594f52a8d4de814ca8284a%7C0&sdata=Bg4sCZ%2FBcfzAgwvnxbWrE2Qt82DogNnIiitUo4A3FF8%3D&reserved=0 or https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnu.org%2Farchive%2Fhtml%2Fbug-make%2F2019-05%2Findex.html&data=01%7C01%7CMartin.Dorey%40hitachivantara.com%7C5aed86365df54e159bc208d6d8dbb855%7C18791e1761594f52a8d4de814ca8284a%7C0&sdata=sn%2FvutWMzNn4KQRviRbEfRXFIw%2FycXmekgPjrzKcG8A%3D&reserved=0 . I'm trying to test libidn with Asan, which is used for internationalized domain names. IDN also uses Gnulib and Gnulib is resisting testing. I can build everything with -fsanitize=address, but Gnulib test runners are doing something such that libasan.so is not being loaded properly. It results in all tests runners failing. The work-around is to LD_PRELOAD libasan.so. Unfortunately for me, that means I have to LD_PRELOAD on the invocation of make. So, running: LD_PRELOAD=/lib64/libasan.so.5 make check Results in: ================================================================= ==19205==ERROR: LeakSanitizer: detected memory leaks Direct leak of 56 byte(s) in 1 object(s) allocated from: #0 0x7feb1d6e1c08 in __interceptor_malloc (/lib64/libasan.so.5+0xefc08) #1 0x55f2ff6d2778 in xmalloc (/usr/bin/make+0x1d778) Indirect leak of 33 byte(s) in 1 object(s) allocated from: #0 0x7feb1d62de60 in strdup (/lib64/libasan.so.5+0x3be60) #1 0x55f2ff6d29ec in xstrdup (/usr/bin/make+0x1d9ec) SUMMARY: AddressSanitizer: 89 byte(s) leaked in 2 allocation(s). It looks like Make's memory leaks are killing the build process long before the test runners execute. It would be nice if Make cleaned up its resources before exiting. The leaks are affecting other components, and they have halted Asan testing for this unit. LD_PRELOAD was my last chance to test this library, and I don't seem to have any other alternatives. I'm working on Fedora 29 with Make 4.2.1, but I have a feeling platform and versions do not matter. Jeff _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnu.org%2Fmailman%2Flistinfo%2Fbug-make&data=01%7C01%7CMartin.Dorey%40hitachivantara.com%7C5aed86365df54e159bc208d6d8dbb855%7C18791e1761594f52a8d4de814ca8284a%7C0&sdata=NOkh6fIatCa01kfLzYjb7YpwBnYkhtXErJtxPNyGBn4%3D&reserved=0
_______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
