Re: Issue with building RPMs with ASAN_ON

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> On 18 Jun 2019, at 17:45, Viktor Ashirov <vashirov@xxxxxxxxxx> wrote:
> 
> 
> 
> On Tue, Jun 18, 2019 at 7:54 AM 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.
> 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;

Heh, selinux strikes again!

Were you running as a user, not as root? 


> 
>  
> 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@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
> 
> 
> -- 
> 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




[Index of Archives]     [Fedora Directory Announce]     [Fedora Users]     [Older Fedora Users Mail]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Review]     [Fedora Art]     [Fedora Music]     [Fedora Packaging]     [CentOS]     [Fedora SELinux]     [Big List of Linux Books]     [KDE Users]     [Fedora Art]     [Fedora Docs]

  Powered by Linux