[polly] r246396 - Do not store into a temporary twine

Evgenii Stepanov via llvm-commits llvm-commits at lists.llvm.org
Mon Aug 31 14:11:48 PDT 2015


-mllvm -asan-check-lifetime=1
-fsanitize-memory-use-after-dtor + MSAN_OPTIONS=poison_in_dtor=1


On Mon, Aug 31, 2015 at 9:57 AM, David Blaikie via llvm-commits
<llvm-commits at lists.llvm.org> wrote:
>
>
> On Mon, Aug 31, 2015 at 9:39 AM, Tobias Grosser <tobias at grosser.es> wrote:
>>
>> On 08/31/2015 06:04 PM, David Blaikie wrote:
>>>
>>> On Sun, Aug 30, 2015 at 12:51 PM, Tobias Grosser via llvm-commits <
>>> llvm-commits at lists.llvm.org> wrote:
>>>
>>>> Author: grosser
>>>> Date: Sun Aug 30 14:51:01 2015
>>>> New Revision: 246396
>>>>
>>>> URL: http://llvm.org/viewvc/llvm-project?rev=246396&view=rev
>>>> Log:
>>>> Do not store into a temporary twine
>>>>
>>>> For some reason, this causes memory corruption issues. Let's just avoid
>>>> it.
>>>>
>>>
>>> Twines are not designed to be named, as such.
>>>
>>> A Twine expresion stores references to Twine subexpressions that are
>>> local
>>> to the C++ full expression - once you are outside that full expression
>>> those references are dangling (as the subexpression Twines are out of
>>> scope).
>>
>>
>> Thanks for explaining. I think I run into a similar issue a couple of
>> months
>> ago. Unfortunately the code that showed the bug does not really give any
>> hint
>> that this is indeed problematic:
>>
>> auto Name = Address->getName() + ".reload";
>>
>> I suppose there is no easy way for us to make this cause a compiler bug or
>> trigger an assert?
>
>
> Not really, no. UBSan could do some lifetime management checking, but even
> that's pretty tricky.
>
> Maybe ASan's (or MSan, is it?) stack lifetime checkers? (I forget what
> they're called, but I think there's some prototype support for this... )
>
>>
>>
>> Best,
>> Tobias
>>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>


More information about the llvm-commits mailing list