[cfe-dev] static Matcher generate Use After Free

[Artem Dergachev via cfe-dev]

Dunno. Crashes i've seen were random, so i'm not sure if being static is 
the only requirement.

Also it seems to have been refactored out a few weeks ago, so there's no 
static matcher here anymore.

06/06/2017 12:45 PM, Maxim Ostapenko wrote:
> On 06/06/17 12:41, Artem Dergachev via cfe-dev wrote:
>> I think i've also noticed that static matcher objects don't work, but 
>> didn't pay enough attention to figure out why.
>>
>> In clang-tidy, as far as i understand, they don't use static 
>> matchers, but instead they have long-lived MatchFinder objects filled 
>> with all the matchers they need, so they don't need to construct the 
>> same matchers again and again. Maybe that'd be a viable approach in 
>> your case?
>
> Hm, but  tools/extra/clang-tidy/modernize/ReplaceAutoPtrCheck.cpp 
> actually has a static matcher:
>
> /// \brief Matcher that finds expressions that are candidates to be 
> wrapped with
> /// 'std::move'.
> ///
> /// Binds the id \c AutoPtrOwnershipTransferId to the expression.
> static StatementMatcher MovableArgumentMatcher =
>     expr(allOf(isLValue(), hasType(AutoPtrType)))
>         .bind(AutoPtrOwnershipTransferId);
>
> Or perhaps I'm missing something?
>
> -Maxim
>
>>
>> 06/06/2017 12:15 PM, Aleksandr wrote:
>>> Hello,
>>>
>>> I need help. I see, that using static Matcher generate error on 
>>> deallocated itself. For example, if we use:
>>> static StatementMatcher MatcherA = callExpr();
>>> MatcherA on dealloc tyrying to release reference counter of itself, 
>>> but reference counter was deleted by method llvm_shutdown, so it use 
>>> free memory.
>>> Is it ok? We shouldn't use static matchers, or we have bug in 
>>> implementation in reference counter. What is it case?
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>