[lld] r194545 - [PECOFF] Fix use-after-return.
Rick Foos
rfoos at codeaurora.org
Thu Nov 14 14:01:33 PST 2013
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
> <mailto:kledzik at apple.com>> wrote:
>
>
> On Nov 14, 2013, at 9:07 AM, Rick Foos <rfoos at codeaurora.org
> <mailto: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>[mailto: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 <mailto: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 <mailto: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 <mailto: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
>> <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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/20131114/c5e18905/attachment.html>
More information about the llvm-commits
mailing list