On Tue, Jun 18, 2019 at 9:50 AM William Brown <wbrown@xxxxxxx> wrote:
> On 18 Jun 2019, at 07:54, Viktor Ashirov <vashirov@xxxxxxxxxx> wrote:
>
> On Tue, Jun 18, 2019 at 1:30 AM Simon Pichugin <spichugi@xxxxxxxxxx> 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.ccindex 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 -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
>> To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
>> 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@xxxxxxxxxxxxxxxxxxxxxxx
>
>
>
> --
> Viktor
> _______________________________________________
> 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxxxx
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Viktor
_______________________________________________ 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
