[apparmor] Memory leaks in parser/parser_regex.c (at least)

[Steve Beattie]

On Sat, Aug 29, 2015 at 10:56:53AM +0200, intrigeri wrote:
> ... and swig/python/test/test-suite.log reads:
> 
> ==13519==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
> FAIL test_python.py (exit status: 1)
> 
> 
> Can it be because the Python interpreter wasn't built with ASan?
> (I was told that whenever a library is built with ASan, all reverse
> build-deps must be built with ASan as well; my knowledge in this area
> is basically non-existing, though, and that's just hearsay.)

I don't really know very much about the details of ASan either. You
could try the following untested patch (not intended for upstreaming,
unless we gain a build configuration option to build with the address
sanitizer):
---
 libraries/libapparmor/swig/python/test/Makefile.am |    1 +
 1 file changed, 1 insertion(+)

Index: b/libraries/libapparmor/swig/python/test/Makefile.am
===================================================================
--- a/libraries/libapparmor/swig/python/test/Makefile.am
+++ b/libraries/libapparmor/swig/python/test/Makefile.am
@@ -15,6 +15,7 @@ PYTHON_DIST_BUILD_PATH = '$(builddir)/..
 
 TESTS	= test_python.py
 TESTS_ENVIRONMENT = \
+  LD_PRELOAD=/usr/lib/${DEB_HOST_MULTIARCH}/libasan.so.1 \
   LD_LIBRARY_PATH='$(top_builddir)/src/.libs:$(PYTHON_DIST_BUILD_PATH)' \
   PYTHONPATH='$(PYTHON_DIST_BUILD_PATH)'
 

However, when I did the manual equivalent of the above, all the python
swig tests failed with multiple leaks detected, some that looked to
be in the python interpreter itself, but some probably from our swig
library -- I'm not really surprised by the latter. A cursory read
of the swig documentation wasn't particularly illuminating in how to
fix those.

> What should be my next step? Skipping these specific tests and looking
> for other potential problems later in the build/test process?

Perhaps. You might try the above patch and see if the resulting
failures [0] are limited to libapparmor and the swig wrapper, or if the
ones that look to be in the python interpreter show up for you, too.

With all the patches I've submitted applied, I didn't get any failures
running the parser (+ libapparmor) built with ASan against its
'make check' tests. Though, given that in the failure mode tests,
we don't check for an explicit exit value, it's still possible that
we're leaking memory in a failure case. (The valgrind script does check
for a valgrind specific exit code.)

Given that we already have lots of outside pressure to make policy
compilation take less time/resources, the near 2 orders of magnitude
time increase it took to run through the simple parser tests with ASan
enabled, I don't think we could justifiably turn it on by default.
But integrating it in some way into automatic tests would be good,
to catch future leaks.

[0] Yes, I'm confident leaks will be detected. :/
-- 
Steve Beattie
<sbeattie at ubuntu.com>
http://NxNW.org/~steve/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20150831/b3ab25e6/attachment.pgp>