similar to: Fwd: buildbot failure in LLVM on llvm-mips-linux

The failure is a bit odd. LLVM is ignoring $PWD because it doesn't have the same inode as '.'. This causes the test failure because DW_AT_comp_dir and $PWD differ. However, $PWD and '.' should be the same inode since $PWD is a symlink to the current directory and stat() looks through symlinks. > Since this latest board only has two cores, it will run slower and it will need

This buildbot seems to have been failing for a while (though it's hard for me to identify the root cause in the logs, as I mentioned in another thread, so it's hard to say if it's the same failure, or if the failure is consistent, etc) - anyone watching it/caring aobut it? ---------- Forwarded message ---------- From: <llvm.buildmaster at lab.llvm.org> Date: Wed, Sep 30, 2015 at

Thanks. From the debugging I've done so far it looks like it could be another 32-bit big-endian specific bug. It seems to be segfaulting in the memset() in allocate_stack.c (from glib) because given stack pointer is null. I'm guessing this is because it read the wrong half of a 64-bit value somewhere but I haven't identified where it goes wrong. ________________________________________

I've just noticed that this is a new test added in r248325 and has never passed on this builder. Added the author of the test (Evgeniy). From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Daniel Sanders via llvm-dev Sent: 01 October 2015 20:34 To: David Blaikie Cc: llvm-dev Subject: Re: [llvm-dev] buildbot failure in LLVM on clang-cmake-mips > > I do. I'll take

This buildbot has been failing for over a week straight ( http://lab.llvm.org:8011/builders/clang-cmake-mips/builds/9387 ) - does anyone know/care about it? ---------- Forwarded message ---------- From: <llvm.buildmaster at lab.llvm.org> Date: Wed, Sep 30, 2015 at 7:49 PM Subject: buildbot failure in LLVM on clang-cmake-mips To: Adrian Prantl <aprantl at apple.com>, Ahmed Bougacha

On Thu, Oct 1, 2015 at 12:08 PM, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > I do. I'll take a look. > > Is there a way for owners to get emails for long-lasting failures? > I'm not sure what the generic setup is, but at least for the builder/slave I admin, it emails me on every failure. So I get a lot of mail, continuously, if there's a consistent

This buildbot appears to have been failing for several weeks now ( http://lab.llvm.org:8011/builders/clang-ppc64-elf-linux2/builds/19490 ). Does anyone know/own/care about it? ---------- Forwarded message ---------- From: <llvm.buildmaster at lab.llvm.org> Date: Mon, Sep 28, 2015 at 11:17 PM Subject: buildbot failure in LLVM on clang-ppc64-elf-linux2 To: Aaron Ballman <aaron at

I can. I've removed every other compilation flags from clang and even used GCC, with the exact same behaviour. cheers, --renato On 29 July 2014 15:15, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote: > OK, we can switch to SIGHUP. Could you please verify that this SIGUSR1 > behavior is not caused by MSan? > > On Tue, Jul 29, 2014 at 6:09 PM, Renato Golin

On Tue, 2015-09-29 at 14:29 -0500, Hal Finkel wrote: > [+Bill and Bill] > > ----- Original Message ----- > > From: "David Blaikie via llvm-dev" <llvm-dev at lists.llvm.org> > > To: "llvm-dev" <llvm-dev at lists.llvm.org> > > Sent: Tuesday, September 29, 2015 12:39:02 PM > > Subject: [llvm-dev] Fwd: buildbot failure in LLVM on

On 29 July 2014 15:02, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote: > You mean replacing SIGUSR1 with SIGHUP in the test case? Weird, I > don't see how they are different. So, AFAIK, they should be identical. But I put some printfs and sleeps around and it wasn't a synchronization issue. My man page says that SIGUSR1 should terminate if there isn't a handler for

Yup, using SIGHUP works. On 29 July 2014 13:14, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote: > Could it be that I'm misunderstanding signal semantics, and SIGUSR1 is > not guaranteed to be delivered (to the same process!) before kill() > returns? Could you check if that's what happens by adding a sleep() > somewhere? > > On Tue, Jul 29, 2014 at 2:17 AM,

Yes, it would be great to get that fixed. On Wed, Feb 5, 2014 at 4:09 PM, Evgeniy Stepanov <eugeni.stepanov at gmail.com>wrote: > On Thu, Feb 6, 2014 at 12:21 AM, Keno Fischer > <kfischer at college.harvard.edu> wrote: > > Looks like when you materialize the stores, you should check the size of > the > > the store and emit an appropriate amount of stores to the

Hi Evgeniy, Yes, it is. The problem here is that the program doesn't fail on my box (release and debug builds), so I have no idea how to debug the problem. According to the test, it's ran as "not chained_origin_with_signals.cc.tmp", expecting it to fail. Also, the FileCheck expects to find warnings on the output, for which there is none Maybe I'm missing some CMake flag or

Looks like when you materialize the stores, you should check the size of the the store and emit an appropriate amount of stores to the origin shadow (or just a memset intrinsic?). On Wed, Feb 5, 2014 at 2:13 PM, Keno Fischer <kfischer at college.harvard.edu>wrote: > The @entry stuff is just a gdb artifact. I've been tracking this back a > little further, and it seems there's

> -----Original Message----- > From: Evgenii Stepanov [mailto:eugeni.stepanov at gmail.com] > Sent: Wednesday, December 07, 2016 4:51 PM > To: Kostya Serebryany > Cc: Robinson, Paul; llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] Debug Locations for Optimized Code > > In fact, we are already using "parallel" debug info. Frame layout > descriptions encode

Hi, we plan to remove -fsanitize-address-zero-base-shadow command line flag from clang, and disable zero-base shadow support on all platforms where it is not the default behavior. - It is completely unused, as far as we know. And completely undocumented, too. - It is ABI-incompatible with non-zero-base shadow, which means all objects in a process must be built with the same setting. Failing to

The code for ccall looks right. Sounds like you have a very small range of instructions where an uninitialized value appear. You could try debugging at asm level. Shadow for b should be passed at offset 0 in __msan_param_tls. MSan could propagate shadow through arithmetic and even some logic operations (like select). It could be that b is clean on function entry, but then something uninitialized

Evgenii Stepanov <eugeni.stepanov at gmail.com> writes: > See https://reviews.llvm.org/D51364 - a very similar bug was > introduced by a compiler-rt change and then fixed by a revert. Ok, so what do we do about this? D50940 seems to have introduced the problem but it was reverted. The "tentative fix" in D51364 was abandoned but it's not clear to me why (maybe because

On Mon, May 13, 2013 at 11:03 AM, İsmail Dönmez <ismail at donmez.ws> wrote: > Hi, > > > On Mon, May 13, 2013 at 10:49 AM, Evgeniy Stepanov > <eugeni.stepanov at gmail.com> wrote: >> >> A recent change added defined(__linux__) condition to the code below. >> Now it says that on linux with --std=c++0x (or --std=c++11) the system >> stdlib.h header

How is ccall() implemented? If it manually sets up a stack frame, then it also needs to store argument shadow values in paramtls. I don't think there is an overflow, unless you have a _lot_ of arguments in a function call. On Sun, Feb 2, 2014 at 9:26 AM, Keno Fischer <kfischer at college.harvard.edu> wrote: > Also, I was looking at the instrumented LLVM code and I noticed that the