LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 21466 - Many memory leaks
Summary: Many memory leaks
Status: RESOLVED FIXED
Alias: None
Product: lld
Classification: Unclassified
Component: All Bugs (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P normal
Assignee: Unassigned LLVM Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-03 15:18 PST by Rafael Ávila de Espíndola
Modified: 2016-03-24 12:42 PDT (History)
5 users (show)

See Also:
Fixed By Commit(s):


Attachments
leaks (59.97 KB, application/octet-stream)
2014-11-03 15:18 PST, Rafael Ávila de Espíndola
Details
asan leaks (35.76 KB, text/x-log)
2016-01-19 17:31 PST, Rafael Ávila de Espíndola
Details
valgrind log (14.77 KB, text/x-log)
2016-01-19 17:32 PST, Rafael Ávila de Espíndola
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rafael Ávila de Espíndola 2014-11-03 15:18:18 PST
Created attachment 13280 [details]
leaks

Attached is the asan output of running just

./bin/llvm-lit -sv ./tools/lld/test/pecoff/trivial.test
Comment 1 Rafael Ávila de Espíndola 2015-07-07 13:05:24 PDT
This is still failing.
Comment 2 Rafael Ávila de Espíndola 2016-01-18 09:50:45 PST
This still fails with, for example, darwin/native-and-mach-o.objtxt.
Comment 3 Peter Cooper 2016-01-19 16:37:43 PST
Thanks for the CC.

I just did 'check-lld' with an asan Debug+Asserts build and I don't get any failures.

Did you do anything here other than set 'LLVM_USE_SANITIZER=Address' in cmake?
Comment 4 Peter Cooper 2016-01-19 17:20:41 PST
Actually, looks like leaks isn't supported on Mac OS :(
Comment 5 Rafael Ávila de Espíndola 2016-01-19 17:30:41 PST
I am able to reproduce this on linux with just

CC=clang CXX=clang++ cmake ../llvm -G Ninja -DCMAKE_BUILD_TYPE=Debug -DLLVM_USE_SANITIZER=Address -DLLVM_ENABLE_ASSERTIONS=ON

and running the test with

./bin/llvm-lit -v  ~/llvm/lld/test/darwin/native-and-mach-o.objtxt

I will attach the output. I was also able to reproduce the problem with valgrind instead of asan.

I am doing a build on OS X to see if it reproduces there.
Comment 6 Rafael Ávila de Espíndola 2016-01-19 17:31:17 PST
Created attachment 15670 [details]
asan leaks
Comment 7 Rafael Ávila de Espíndola 2016-01-19 17:32:43 PST
Created attachment 15671 [details]
valgrind log
Comment 8 Rafael Ávila de Espíndola 2016-01-19 17:34:54 PST
(In reply to comment #4)
> Actually, looks like leaks isn't supported on Mac OS :(

:-(

Do you have access to a linux machine (or is valgrind supported on current OS X? It used to work in the past).
Comment 9 Peter Cooper 2016-01-19 20:29:17 PST
(In reply to comment #8)
> (In reply to comment #4)
> > Actually, looks like leaks isn't supported on Mac OS :(
> 
> :-(
> 
> Do you have access to a linux machine (or is valgrind supported on current
> OS X? It used to work in the past).
Afraid I don't have access to a Linux machine.  But I was able to repro the leaks in Instruments on Mac OS.  

Its coming from MappingNormalizationHeap on at least a few of the tests.  In the non io.outputting() case we are allocating (typically) atoms, but somehow these are getting dropped.

I'd have expected all atoms to get to the pass pipeline and only be dropped by (for example) dead strip in the resolver, so i'll need to see where we are dropping the parsed atoms.
Comment 10 Peter Cooper 2016-03-16 18:34:44 PDT
Fixed some of these in r263676/r263677.

Looking now to see what else is still leaking.
Comment 11 Peter Cooper 2016-03-24 12:42:13 PDT
There were a whole bunch more commits over the last few days.  The final known ASan leak was fixed in r264097.  UBSan is also clean as of r264234.