On Tue, Jun 24, 2014 at 12:29:23PM +0300, Nikolai Kondrashov wrote: > On 06/24/2014 09:55 AM, Jakub Hrozek wrote: > >On Wed, Jun 11, 2014 at 07:34:31PM +0300, Nikolai Kondrashov wrote: > >>On 06/11/2014 05:54 PM, Pavel Reichl wrote: > >>We can use Valgrind suppressions to achieve something close to this. Clang > >>doesn't seem to have such facility, but it is probably possible to implement > >>one which would process resulting XML files. > > > >Kamil Dudka of Red Hat (kdudka@r.c) has developed a tool that does exactly > >this > >diffing for Coverity results. When we talked about this tool about a > >year ago maybe, the didn't have the same functionality for Clang > >diffing, but maybe times have changed :-) > > > >Would you like to ping him or should I ? > > I see minor references to Clang in the source code, but none in the > documentation, so it's not clear. I would be grateful, if you'd ping him. > > However, I should note that there are no csdiff packages in Debian repos, > which means Debian users will be out in the cold either skipping this test, or > perhaps using "alien" to install csdiff.
I will ask Kamil, but it indeed looks like nothing was implemented. (which is in line with what he'd told me earlier - patches welcome) > > >>However, I think that effort to do this is much greater than the effort > >>required to bring errors/warnings to zero, using various exception > >>mechanisms > >>where necessary, and then simply keeping it there. > > > >When you're talking about warnings and errors, what valgrind mode do you > >have in mind? Also leaks or "just" bad memory access? If the former, > >then I think that's a large goal (NSS the crypto library would need an > >elaborate suppression file..), but the latter I think we should > >achieve. Did you see anything like undefined memory access during your > >CI patch testing? I would consider those an SSSD bug. > > I was talking about the default tool, memcheck. Currently CI checks for error > counts, which include lost memory blocks and there are a lot of them. Pity > about the NSS, I see that crypto-tests shows many leaks from it, although > these are still not the majority. > > I would say we can manage the suppressions for those leaks that we can't/won't > fix at the moment (wildcard them, if necessary) and fix the rest. > > An in-tree suppressions file, which can be modified in a single commit with a > code change and then verified by the CI, seems to me almost as good as a > report difference tracking tool and much easier to implement. Yes, we can try this way. I wonder how much effort will it be to manage the suppresion files, though, NSS is not the most stable software out there. > > Valgrind also supports outputting information on which suppressions were > actually used, so in time we will be able to use that to remove unused > suppressions, not only to add new ones. > > >>One thing that would probably need this is code coverage tracking. I'm > >>considering storing at least the overall score somewhere and comparing each > >>run to the previous commit, alerting on reduction. However, I wouldn't > >>attempt > >>to implement this right now, as it is mostly a convenience. Perhaps a few > >>months later. > > > >yep. btw what about a Trac Milestone that would list all these CI > >enhancements, maybe also tests we want to implement? > > This sounds good. I haven't found a way to create a milestone myself, so I > assume I'm not permitted to. Could you please do it? OK, I added "SSSD Continuous integration" milestone. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
