[lld] r194545 - [PECOFF] Fix use-after-return.

Thu Nov 14 14:47:06 PST 2013

+kcc, samsonov (please don't remove people from CC)

You mean in the presence of threads? There's no such option because it's
not supposed to interfere with the symbolizer. If it does then it's a bug,
someone from our team will follow up on this tomorrow.

Sergey

On Fri, Nov 15, 2013 at 2:01 AM, Rick Foos <rfoos at codeaurora.org> wrote:

>  Thank you Sergey!
>
> Address Sanitize running alone on a server is stable without the
> symbolizer option. It is running all the tests in a reasonable amount of
> time, and there are no llvm-symbolizer tasks.
>
> The problem is coming from Threads, and I'm trying to prove that now.
>
> If threads runs clean by itself alone on a server, there is an interaction
> with both address and threads running at the same time.
>
> Is there a similar feature to disable symbolizer in threads?
>
> Best Regards,
> Rick
>
>
> On 11/14/2013 03:51 PM, Sergey Matveev wrote:
>
> ASAN_OPTIONS=symbolize=false
>
>
> On Fri, Nov 15, 2013 at 1:14 AM, Nick Kledzik <kledzik at apple.com> wrote:
>
>>
>>  On Nov 14, 2013, at 9:07 AM, Rick Foos <rfoos at codeaurora.org> wrote:
>>
>>   Status: System in swap overnight. Stopped both buildmaster and slave.
>> 187 llvm-symbolizer tasks were still running. Tasks did not stop after
>>
>>  Retried this morning, no other workload, 8 llvm-symbolizer tasks
>> consuming 100% on each cpu
>>
>>
>>  Doesn’t that mean that Asan found some problems, but is stuck trying to
>> symbolicate the backtraces?   Is there a way to run Asan and *not*
>> symbolicate?
>>
>>  This also seems like a bug (infinite loop?) in llvm-symbolizer.
>>
>>  -Nick
>>
>>
>>   . 7 zombie tasks.
>>
>>  So not quite ready this morning. If anyone knows of an llvm-sanitizer
>> issue like this it would help.
>>
>>   *From:* llvm-commits-bounces at cs.uiuc.edu [
>> mailto:llvm-commits-bounces at cs.uiuc.edu<llvm-commits-bounces at cs.uiuc.edu>
>> ] *On Behalf Of *Rick Foos
>> *Sent:* Wednesday, November 13, 2013 1:42 PM
>> *To:* Sergey Matveev; Shankar Easwaran
>> *Cc:* llvm-commits at cs.uiuc.edu; Galina Kistanova
>> *Subject:* Re: [lld] r194545 - [PECOFF] Fix use-after-return.
>>
>>  Sorry for the delay,
>>
>> Our problem with running the sanitizers is that the load average running
>> under Ninja reached 146 and a short time after a system crash requiring
>> calling someone to power cycle the box...
>>
>> The address sanitizer by itself leaves a load average 40. This means the
>> OS over 100% utilization, and is thrashing a bit. Load Average doesn't say
>> what exactly is thrashing.
>>
>> Ninja supports make's -j, and -l options. The -l maximum load average, is
>> the key.
>>
>> The load average should be less than the total number of cores
>> (hyperthreads too) before Ninja launches another task.
>>
>> A Load Average at or lower than 100%  technically should benefit
>> performance, and maximize throughput. However, I will be happy if I don't
>> have to call someone to power cycle the server :)
>>
>> So the maximum load average of a 16 core machine with hyperthreads is 32
>> (keeping it simple). This needs to be passed to all make's and Ninja build
>> steps on that slave to maximize throughput.
>>
>> For now, I'm looking at a minimal patch to include jobs and a new
>> loadaverage variable for the sanitizers.
>>
>> Longer term, all buildslaves should define maximum loadaverage, and all
>> make/ninja steps should pass -j, and -l options.
>>
>> Best Regards,
>> Rick
>>
>> On 11/13/2013 11:21 AM, Sergey Matveev wrote:
>>
>>  +kcc
>>
>>
>>  On Wed, Nov 13, 2013 at 6:41 AM, Shankar Easwaran <
>> shankare at codeaurora.org> wrote:
>> Sorry for another indirection. Rick foos is working on it. I think there
>> is some good news here :)
>>
>> Cced Rick + adding Galina,Dmitri.
>>
>> Thanks
>>
>> Shankar Easwaran
>>
>>
>> On 11/12/2013 8:37 PM, Rui Ueyama wrote:
>>
>> Shankar tried to set it up recently.
>>
>>
>> On Tue, Nov 12, 2013 at 6:31 PM, Sean Silva <silvas at purdue.edu> wrote:
>>
>> Sanitizers?
>>
>> There have been a couple of these sorts of bugs recently... we really
>> ought to have some sanitizer bots...
>>
>> -- Sean Silva
>>
>>
>> On Tue, Nov 12, 2013 at 9:21 PM, Rui Ueyama <ruiu at google.com> wrote:
>>
>> Author: ruiu
>> Date: Tue Nov 12 20:21:51 2013
>> New Revision: 194545
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=194545&view=rev
>> Log:
>> [PECOFF] Fix use-after-return.
>>
>> Modified:
>>      lld/trunk/lib/Driver/WinLinkDriver.cpp
>>
>> Modified: lld/trunk/lib/Driver/WinLinkDriver.cpp
>> URL:
>>
>> http://llvm.org/viewvc/llvm-project/lld/trunk/lib/Driver/WinLinkDriver.cpp?rev=194545&r1=194544&r2=194545&view=diff
>>
>>
>> ==============================================================================
>> --- lld/trunk/lib/Driver/WinLinkDriver.cpp (original)
>> +++ lld/trunk/lib/Driver/WinLinkDriver.cpp Tue Nov 12 20:21:51 2013
>> @@ -842,7 +842,7 @@ WinLinkDriver::parse(int argc, const cha
>>
>>       case OPT_INPUT:
>>         inputElements.push_back(std::unique_ptr<InputElement>(
>> -          new PECOFFFileNode(ctx, inputArg->getValue())));
>> +          new PECOFFFileNode(ctx,
>> ctx.allocateString(inputArg->getValue()))));
>>         break;
>>
>>   #define DEFINE_BOOLEAN_FLAG(name, setter)       \
>> @@ -892,9 +892,11 @@ WinLinkDriver::parse(int argc, const cha
>>     // start with a hypen or a slash. This is not compatible with link.exe
>>     // but useful for us to test lld on Unix.
>>     if (llvm::opt::Arg *dashdash = parsedArgs->getLastArg(OPT_DASH_DASH))
>> {
>> -    for (const StringRef value : dashdash->getValues())
>> -      inputElements.push_back(
>> -          std::unique_ptr<InputElement>(new PECOFFFileNode(ctx, value)));
>> +    for (const StringRef value : dashdash->getValues()) {
>> +      std::unique_ptr<InputElement> elem(
>> +          new PECOFFFileNode(ctx, ctx.allocateString(value)));
>> +      inputElements.push_back(std::move(elem));
>> +    }
>>     }
>>
>>     // Add the libraries specified by /defaultlib unless they are already
>> added
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>>
>>
>>  --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
>> by the Linux Foundation
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>>
>>
>>
>>  _______________________________________________
>>
>> llvm-commits mailing list
>>
>> llvm-commits at cs.uiuc.edu
>>
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>>
>>
>>
>>  --
>>
>> Rick Foos
>>
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
>>
>>  _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>>
>>
>
>
> --
> Rick Foos
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131115/a908533a/attachment.html>