> On 18 Jun 2019, at 07:54, Viktor Ashirov <vashirov@redhat.com> wrote:
>
> On Tue, Jun 18, 2019 at 1:30 AM Simon Pichugin <spichugi@redhat.com> 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?

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".

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).

>>
>> 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 -- 389-devel@lists.fedoraproject.org
>> To unsubscribe send an email to 389-devel-leave@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.fedoraproject.org
>
>
>
> --
> Viktor
> _______________________________________________
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-leave@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.fedoraproject.org

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-leave@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.fedoraproject.org