r310401 - PR19668, PR23034: Fix handling of move constructors and deleted copy

[Diana Picus via cfe-commits]

On 15 August 2017 at 01:25, Richard Smith <richard at metafoo.co.uk> wrote:
> On 14 August 2017 at 03:27, Diana Picus via cfe-commits
> <cfe-commits at lists.llvm.org> wrote:
>>
>> Hi,
>>
>> Strangely enough, it turns out that if I run
>> Asan-armhf-with-calls-Noinst-Test on the command line it fails,
>> although it doesn't fail when run with lit.
>
>
> Looks like the crash is within the "use_colors == true" portion of
> ColoredPrintf, so this would make sense if running the test within lit turns
> off color support (perhaps because the output is not a terminal).
>

That's a good catch, it seems if I run it with --gtest-color=no it
still passes, but prints some garbage at the end:
[ PASSED ] 97 tests.
YOU HAVE -1094542056 DISABLED F]�뀼��_8�pG����D2


>>
>> I've attached the stack
>> trace from gdb. It looks like some trouble passing down va_arg
>> parameters, but I haven't looked into too much details. The segfault
>> happens when we try to do a   ldrb   r3, [r0, r1], with r1 set to 0 by
>> the current function and r0 passed down from the caller. I'm not sure
>> if this is the exact same problem as the other tests, but feel free to
>> have a look at that code.
>
>
> Have you tried running Asan-armhf-with-calls-Noinst-Test on the command line
> without this patch applied? (It's possible that this is a pre-existing bug
> in ARM varargs call lowering, and is unrelated to the bug we're trying to
> track down. This code path performs an unrelated varargs call between a
> va_start / va_end pair, which seems like quite a rare situation, and I could
> easily believe there's something wrong with our lowering that allows some
> portion of the outer va_list state to be clobbered in that scenario.)
>

It seems to work without the patch. I'm currently trying to reduce
Asan-armhf-with-calls-Test and I'll get back to you with the IR or
assembly files (whichever makes any difference).

>> Meanwhile, I've removed some clutter from Asan-armhf-with-calls-Test
>> (which is the original failure that we were seeing) and left only one
>> failing test that seemed small enough. I'll try to look at the
>> disassembly before/after the patch and maybe even run valgrind on it
>> (running it on the original binary naturally takes forever).
>>
>> Let me know if there's anything else I could try. I can also send you
>> disassembly or even LLVM IR for the Asan-armhf-with-calls-Noinst-Test
>> if you think it helps.
>>
>> Cheers,
>> Diana