On Tue, Jun 18, 2019 at 9:50 AM William Brown <[email protected]> wrote:
> > > > On 18 Jun 2019, at 07:54, Viktor Ashirov <[email protected]> wrote: > > > > On Tue, Jun 18, 2019 at 1:30 AM Simon Pichugin <[email protected]> > wrote: > >> > >> Hi team, > >> I'm in the process of creating a Vagrant file which is close to the > customer's ENV. > >> It is heavilly based on Viktor's beaker task. > >> I use it for building and testing my code. And it is pretty important > to build with ASAN. > >> > >> Currently, what I do is: > >> 1. Set 'ASAN_ON = 1' in rpm.mk > >> 2. Run `make -f rpm.mk srpms` target > >> 3. Build the RPM using `mock -q my_generated.srpm` > >> 4. Install it > >> > >> Then I've tried running `dscreate` manually or running tests with > py.test. > >> Every time I have the same error here: > /run/dirsrv/ns-slapd-standalone1.asan.XXXXX > >> > >> ==22487==LeakSanitizer has encountered a fatal error. > >> ==22487==HINT: For debugging, try setting environment variable > LSAN_OPTIONS=verbosity=1:log_threads=1 > >> ==22487==HINT: LeakSanitizer does not work under ptrace (strace, > gdb, etc) > > Ludwig also recently had this issue. Looks like you're hitting this > > bug: https://github.com/google/sanitizers/issues/723 > > We're using posix_memalign() in a few places and LeakSanitizier can't > handle it. > > There is a workaround in the last comment. I did the builds for gcc8 > > and gcc9 in copr, both internal and fedora one, but they failed (not > > related to the patch). > > So I did a local build with the patch and it worked like a charm. I > > will share the links to the rpms for you to try. > > Which patch? > The patch with the workaround mentioned in https://github.com/google/sanitizers/issues/723 diff --git a/libsanitizer/lsan/lsan_common.cc b/libsanitizer/lsan/lsan_common.cc index a4424a887..77d522da6 100644 --- a/libsanitizer/lsan/lsan_common.cc +++ b/libsanitizer/lsan/lsan_common.cc @@ -582,7 +582,7 @@ static bool CheckForLeaks() { "LSAN_OPTIONS=verbosity=1:log_threads=1\n"); Report( "HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)\n"); - Die(); + return false; } param.leak_report.ApplySuppressions(); uptr unsuppressed_count = param.leak_report.UnsuppressedLeakCount(); > > > > > Perhaps we should review our usage of posix_memalign() or convince the > > upstream to implement a proper fix for this. > > Memalign is pretty important - the short version is "we can not remove it". > I didn't say "remove", I said "review". > > There are some structures in the code that rely on this for performance to > guarantee that they memory is aligned to a page boundary, or cache line > boundary. In some cases it's required to allow the atomics to work in > nunc-stans (well, lfds, but the value of that today is questionable when > the rust version is possibly safer and faster). > Since you're the expert in this area, maybe you can leave a comment in the issue linked above with the justification for upstream to reconsider? > > >> > >> I've tried setting `export LSAN_OPTIONS=verbosity=1:log_threads=1` and > run once again. > >> Same issue. > >> > >> Did anybody encountered the issue? Maybe, Viktor or William, could you > please check? > >> I'm putting the Vagrantfile to the attachments so you can reproduce. > >> Just run: `ASAN=on vagrant up` from the directory with Vagrantfile. > >> > >> William, I think, libvirt is present on SUSE so you should have no > issues with this too... > > It is, but I run on a mac so ... my setup is fun fun fun :) > > I would normally run this on my home lab, but I'm a few thousand km's away > .... > > >> > >> Thanks, > >> Simon > >> _______________________________________________ > >> 389-devel mailing list -- [email protected] > >> To unsubscribe send an email to [email protected] > >> Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > >> List Archives: > https://lists.fedoraproject.org/archives/list/[email protected] > > > > > > > > -- > > Viktor > > _______________________________________________ > > 389-devel mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedoraproject.org/archives/list/[email protected] > > — > Sincerely, > > William Brown > > Senior Software Engineer, 389 Directory Server > SUSE Labs > _______________________________________________ > 389-devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/[email protected] > -- Viktor
_______________________________________________ 389-devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected]
