On 11/08/2016 10:12 AM, Jakub Jelinek wrote:
> On Tue, Nov 08, 2016 at 09:58:13AM +0100, Martin Liška wrote:
>> Problematic is lambda function (use-after-scope-ice-1.ii.004t.gimple):
>> C::AsyncCloseConnectionWithErrorMsg(const A&)::<lambda()> (const struct
>> __lambda0 * const __closure)
>> {
>> const struct A message [value-expr: __closure->__message];
>> struct C * const this [value-expr: __closure->__this];
>>
>> try
>> {
>> ASAN_MARK (2, &message, 4);
>
> That shows that the ASAN_MARK adds the &message without going through
> gimplify_expr on it and therefore not handling the DECL_VALUE_EXPR in it,
> otherwise it would be
> _2 = &__closure->__message;
> ASAN_MARK (2, _2, 4);
> or something similar.
> That said, poisoning/unpoisoning the lambda captured vars inside of the
> lambda is of course wrong, 1) you really don't know where the members
> live, it could be on the stack, but could very well be on the heap or
> elsewhere, and while for stack and say longjmp we are prepared to unpoison
> it, for heap allocated vars you risk you keep the memory poisoned in corner
> cases and nothing will ever unpoison it; 2) the captured vars live longer
> than just in the lambda method, it is perhaps up to whatever function
> creates the lambda var to poison/unpoison it.
>
>> _1 = __closure->__this;
>> C::DispatchConnectionCloseEvent (_1, __closure->__message);
>> }
>> finally
>> {
>> ASAN_MARK (1, &message, 4);
>> }
>> }
>>
>> Where for quite obvious reasons variables 'message' can't be put as a stack
>> variable and ICE is triggered in:
>> /tmp/use-after-scope-ice-1.ii:31:23: internal compiler error: in
>> make_decl_rtl, at varasm.c:1311
>>
>> My question is how to properly identify local variables defined in __closure
>> context? Is it somehow
>> related to DECL_HAS_VALUE_EXPR_P field set on a var?
>
> So yes, you should just ignore vars with DECL_HAS_VALUE_EXPR_P. That can
> mean lots of things (e.g. heavily used for OpenMP/OpenACC/Cilk+), but I
> can't think of a case which you would like to poison - if it is
> DECL_VALUE_EXPR to another var of part thereof, the other var should still
> be declared in its scope.
Thank you for clarification, I'm testing patch for this and other fallout
issues.
Martin
>
> Jakub
>
