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)

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... Thanks, Simon _______________________________________________ 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org 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/389-devel@lists.fedoraproje...

> > 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? You mean upstream LSAN/ASAN in this case, yes?

— Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org 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/389-devel@lists.fedoraproje...

> On 18 Jun 2019, at 14:19, Viktor Ashirov <vashirov(a)redhat.com&gt; wrote: > > > > On Tue, Jun 18, 2019 at 2:10 PM William Brown <wbrown(a)suse.de&gt; wrote: > > > > > 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? > > You mean upstream LSAN/ASAN in this case, yes? > Yes, this https://github.com/google/sanitizers/issues/723 Reading the report, that is only about mprotect of alligned memory, not of memory that is just aligned. Perhaps our issue is different? Maybe. I only tried the workaround that worked for me. At least I got some

> > > — > Sincerely, > > William Brown > > Senior Software Engineer, 389 Directory Server > SUSE Labs > _______________________________________________ > 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org > To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org > 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/389-devel@lists.fedoraproje... > > > -- > Viktor > _______________________________________________ > 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org > To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org > 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/389-devel@lists.fedoraproje... — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org 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/389-devel@lists.fedoraproje...

> On 18 Jun 2019, at 14:38, Viktor Ashirov <vashirov(a)redhat.com&gt; wrote: > > > > On Tue, Jun 18, 2019 at 2:33 PM William Brown <wbrown(a)suse.de&gt; wrote: > > > > On 18 Jun 2019, at 14:19, Viktor Ashirov <vashirov(a)redhat.com&gt; wrote: > > > > > > > > On Tue, Jun 18, 2019 at 2:10 PM William Brown <wbrown(a)suse.de&gt; wrote: > > > > > > > > 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? > > > > You mean upstream LSAN/ASAN in this case, yes? > > Yes, this https://github.com/google/sanitizers/issues/723 > > Reading the report, that is only about mprotect of alligned memory, not of memory that is just aligned. Perhaps our issue is different? > > Maybe. I only tried the workaround that worked for me. At least I got some sensible results, not just LeakSanitizer failure. Where did you find the work around? Maybe I'm blind, but I do not see it on this issue ....

> > > > > > > — > > Sincerely, > > > > William Brown > > > > Senior Software Engineer, 389 Directory Server > > SUSE Labs > > _______________________________________________ > > 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org > > To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org > > 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/389-devel@lists.fedoraproje... > > > > > > -- > > Viktor > > _______________________________________________ > > 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org > > To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org > > 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/389-devel@lists.fedoraproje... > > — > Sincerely, > > William Brown > > Senior Software Engineer, 389 Directory Server > SUSE Labs > _______________________________________________ > 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org > To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org > 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/389-devel@lists.fedoraproje... > > > -- > Viktor > _______________________________________________ > 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org > To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org > 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/389-devel@lists.fedoraproje... — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org 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/389-devel@lists.fedoraproje...

Date: Tue, 18 Jun 2019 07:54:43 +0200 From: Viktor Ashirov <vashirov(a)redhat.com&gt;

On Tue, Jun 18, 2019 at 1:30 AM Simon Pichugin <spichugi(a)redhat.com&gt; 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. Perhaps we should review our usage of posix_memalign() or convince the upstream to implement a proper fix for this.

On 18 Jun 2019, at 17:45, Viktor Ashirov <vashirov(a)redhat.com&gt; wrote: On Tue, Jun 18, 2019 at 7:54 AM Viktor Ashirov <vashirov(a)redhat.com&gt; wrote: On Tue, Jun 18, 2019 at 1:30 AM Simon Pichugin <spichugi(a)redhat.com&gt; 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. So, the issue Simon was seeing is not related to the issue above. Turns out, it's just SELinux :) ---- time->Tue Jun 18 11:27:24 2019 type=AVC msg=audit(1560871644.883:596): avc: denied { ptrace } for pid=3632 comm="ns-slapd" scontext=system_u:system_r:dirsrv_t:s0 tcontext=system_u:system_r:dirsrv_t:s0 tclass=process permissive=0 [root@server ds]# ausearch -m AVC | audit2allow #============= dirsrv_t ============== allow dirsrv_t self:process ptrace;

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. Perhaps we should review our usage of posix_memalign() or convince the upstream to implement a proper fix for this. > > 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... > > Thanks, > Simon > _______________________________________________ > 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org > To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org > 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/389-devel@lists.fedoraproje... -- Viktor -- Viktor _______________________________________________ 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org 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/389-devel@lists.fedoraproje...